[chirp_devel] Modernizing

[Dan Smith]

Jim, Rick, if you've been ignoring this repeat discussion: questions for you at the end.

Derek, passion and snark to follow, please read to the end :)

> Hi dan - Thanks for the well thought out responses. To be clear, I am an avid user of chirp first and foremost. I am also not they type of person to complain about a problem without proposing a solution. For me, personally, the main issue with using Chirp is that it doesn't work and feel like a windows app. Things like tab and ctrl+c don't work the way you would expect, and operting on memories in the grid view doesn't work like most windows apps that have grid views. So the upgrading frameworks and python is all about trying to do what's right for the users.

I thought python3 was a psychological thing? :)

The keybindings thing is something we can solve, and moving to GTK3 won't have any effect. I'm not sure GTK3 will make the gridview behave any more natively, but if so, that would be great. It works natively for me on my platforms, and even when I use it on Windows I don't really notice that it's any different, but I know some people have issues with it.

> It's also worth noting that I have several little things i have worked on for my suported radios that have not made it back in because I'm a bit daunted by the process (not that they are high demand features - likely I'm one of the very few who cares about scan edges, call channels and settings for an ic2720h).
> 
> Re: git/github - I have very little experience with hg (chirp is it), so most of my comments are based on experience with git and reading about hg.

Seriously? I mean, there are a lot of not-even-developers that figure it out all on their own. With all due respect, if you haven't actually gone through the process of generating a patch and sending it yet, I'd like you to do that before you judge it and suggest we all move to the thing you're most comfortable with :)

With all due respect, people show up all the time complaining about our process (or something else), having never submitted a patch and wanting the process to change before they do. People who have actually contributed something have a lot more voice around here than those that haven't. Since a move to github and working on python3/GTK3/whatever-else are relatively separate, maybe you could help work on some of the latter to build some familiarity with what we have? The "I want to contribute, but not until you change everything about how you work to be like I want" sort of attitude really rubs me the wrong way. I know that's an exaggeration of what you've said, I'm just hyperbolizing it for effect :)

> To clarify, when I was talking about documentation, I was specifically talking about github.io, not simply the repo docs (and of course Jens' reply comes in as I am writing this saying the same thing). There are utils out there to convert docs from redmine to md/gitlab/etc... including workitems and history. I actually think it's easier to create a giuthub account and report an issue than the current workflow. Currently, the link to issues takes me to a page that shows issues, but ther eis no "new issue" button there. I have to create an account, login and then there is a new issue tab that subtly shows up in the navbar. With github, you provide a link from the main page to issues, there is a new issue button right there, and when you click it, if you are not logged in it opens a popup to create an account or login.

Are you really suggesting that the lack of a "create" button that makes you log in is a major factor for moving our entire platform? I mean, really now :)

We have a "how do I report an issue" FAQ entry and could do plenty to make it more obvious if you really find that to be a struggle. To be honest, I hear more people complain that they can't find the download that they need than anything about not knowing how to report issues, FWIW.

> Yes, they may go to a profile page, but that's really okay. I don't tihnk most people will have a hard time figuring out how to get back to the issues page. There is the added benefit that once they have an account, they are all set to become a contributor should they so desire, and their bugs and contributions will all be tied to that account.

Yeah, and again, you're not on the other end of all the emails I get about the process, so you'll just have to trust me that the above sounds very simple to you, as you're familiar with it and clearly much more technically capable than the average bug-filing contributor. I used to get a ton of emails from people who couldn't find the Download link at the top of the page until Tom put a comically-large "CLICK HERE TO DOWNLOAD" icon (which has since been de-comically-ized a bit).

> Also, not to get too argumentative, but you say that you don't want to force existing contributors to learn git but also say that git and hg are so similar that git users should have no problem using HG. So far the only discussion I have seen indicates that contributors know how to use git today, and if it's easy to convert from git to hg then it should be easy to provide a simple guide to converting from hg to git.

For someone that knows nothing to learn hg and then convert to git, it's a hurdle. For someone who already knows a distributed SCM and the ideas, it's much less of an issue.

> At work, we enforce squash before committing to master, so we have a very clean commit history in master. The downside is that in many cases the rebase that was originally 50 commits should really be several commits, but ends up as 1 commit. As Jens alluded to, this can be addressed by requiring contributors to rebase into a sane branch with commits that make sense (e.g. for feature X, commit 1 is backend added function y, 2 is added unit test, 3 is added UI support, etc...).

Yep, I know you can do this, and document it for people that read them before submitting. I'm just saying that the workflow tends to generate that behavior, which is definitely does. It's manageable and not insurmountable.

> Re: Python 2.7 vs 3, this is a psychological thing. We hire a lot of young developers at work, and they tend to gravitate towards the projects that are using the more modern technologies. E.g. if I have an old service using entity framework, .net 4 and mvc + node js, or a service using .net core microservices with a kendo/angular based ui, they want to work on the latter (at least I didn't propose moving the UI to .net core 😊 ).

On the other hand, chirp deals with relatively legacy technology anyway, in the form of crusty old radios. Maybe we're missing a huge batch of young, enthusiastic people that want to contribute and just can't get over the fact that we're not on github, but I just don't get that feeling.

> As a new contributor myself, I would like to bring something to the table. I'm a service engineer by trade, so coding is secondary to my day job, but I am trying to write more code.I was thinking for a start, I would work through Python's own guide for upgrading. To me the following makes sense:
> 
> Run the non-ui through the python guide to upgrading which starts with supporting both. Stop short of cutting 2.7 support. This is necessary to upgrade regardless of the UI choice so I think it should come first.
> Evaluate the UI functions for anything else that can be further abstracted.
> In parallel, keep up the UI discussion. If we have to port to PyGObject, does it make sense to stick with GTK, or should we looks at other UI frameworks?

If you pursue the PyGObject thing, I think you can do that without python3-ifying everything if I'm not mistaken. That might be a path worth going  down first just to decide if it's worth doing that or going with a different framework. If you sanitize the non-UI code and then the UI replacement never materializes (and let's be honest, it's a lot of work that may very well never happen), then you've done that work for relatively little gain. But, it's your time and thus your call. You're more than welcome to do that on github if you like, but it would sure build a lot of karma if you used it as an opportunity to bolster your list of grievances with mercurial :)

On the git and/or github conversation, I really want to hear from people like Jim and maybe Rick. Jim has contributed a ton to chirp, and if he was less likely to work on stuff if it was in git, then that's a non-starter for me. Rick has (I think, not sure) been struggling with the SCM process in general, so I'd like to hear if he's more comfortable with git, or if he'd be okay pivoting to something else with a slightly different workflow. If these guys are okay with switching and learning something else (or with trying to continue using mercurial from a mirrored tree, which I could maintain), then we could think about moving to git.

I'd like to maybe separate the github discussion from git, as I do think they're different things. I really feel strongly about the concern for users having to use github for filing bugs, but I can disable that on the repo to avoid forking the bug history for the moment. And I guess I could respond to patches on the ML and PRs in parallel, at least as a trial. Would that be a reasonable step for the github-loving crowd?

--Dan