[chirp_devel] Modernizing

[Derek Chauran]

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. 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.

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. 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.

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.

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...).

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 😊 ).

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?

Thanks,
Derek



________________________________
From: Dan Smith <dsmith at danplanet.com>
Sent: Saturday, June 9, 2018 8:25 AM
To: Derek Chauran; chirp_devel at intrepid.danplanet.com
Subject: Re: [chirp_devel] Modernizing

> I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
>
> What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub?

Before I answer further, I'd like to say that I write python3 for my day job, I use git exclusively these days, I contribute to many projects on github (large and small), and maintain several projects there and take PRs from people. I say this to make it clear that I'm definitely not afraid of the unknown :)

> Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language.

Honestly I really don't understand this argument. There is so little (that affects chirp) that differs between 2.7 and 3.x. Unless it's just a psychological thing or something, but.. meh :)

> As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.

I get that. I use git exclusively now myself. I understand the desire to appeal to new contributors, but those contributors haven't actually brought anything to the table yet. There are a bunch of contributors that have written and maintain large chunks of chirp code that didn't know another system and learned mercurial to be able to do that. Switching may not be a problem for them, but it's not a zero effort change, and I really (really) want to continue to make things easy for them. I certainly don't want to prioritize the contributors that may exist over those that do. Mercurial is so similar to git that I also really don't understand people that say they don't want to contribute because it requires learning a new (but similar) tool. Learning what you need to write a coherent patch against chirp is like an order of magnitude more work than learning how to hg clone, hg commit, hg email.

Moving to git is also a separate concern from moving to github to me. The two need not be tied together, IMHO.

> There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made.
>        • No XP support past Python 3.5. I think this is actually a good thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade.

Well, you can think it's silly but it's a reality. Not long ago I refreshed the build image for Windows and used Windows 7, thinking it was time. The next two days of emails I got from people made it pretty clear that a ton of users still run on XP and so I re-re-built it on XP. I am not a windows user, but the only physical windows machine I have is XP, which is purpose-built for specific tasks, so I get it. It's also the only one I have with a real serial port, which is, quite relevant.

>        • With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows).

No, we don't "get" GTK3, we are "forced" to move to PyGObject. Now, this is not a problem in and of itself, except that it's a big chunk of work that nobody has done yet. If you want to queue up all the changes required to change the UI to use PyGObject, I will happily review it and do the work to make the build image use it. Several people have expressed interest, but none have actually done it.

If this happens, then we can move to Python 3 by default for sure, and allow things up to 3.5 or whatever still runs on XP. I don't think I'm ready to drop support for XP yet, and since I'm the recipient of all the complaints that will come, hopefully that's understandable.

> Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...)

What does this have to do with writing new UIs? There is a very clean seam between the UI and the non-UI stuff. There are routines in the UI that would be re-usable by others, and could easily be brought across that seam for re-use, but that would be very minor compared to the work of actually writing a new UI to meet the level of functionality we currently have. If you're interested in this, please feel free.

>        • Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests.

I definitely don't understand this. Mercurial and git are extremely similar. Branches in mercurial are a thing, if you want to use them, and you can use the commit workflow instead of mq and patchbomb those the same way. The mq workflow makes a lot of sense for small changes against upstream which are easy to add, remove, update and delete. Patchbomb just emails the commits that mq creates, and you can patchbomb any other commit that you want, if you don't want to use mq.

I've used github extensively, as well as many other similar git-based things. I'm not a huge fan of the PR workflow, the way code gets reviewed (or not) on github, and definitely not a fan of the really nasty commit history patterns that github tends to encourage of people. That said, I use it a lot and can certainly deal with it.
>
>        • Git is destructive - This is not really true. In fact, the opposite is true.  When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow.

I'm not sure what your point here is. I've never heard this argument, so it definitely doesn't factor into my feelings on the matter :)

>        • Github comes with its own documentation/hosting system with native support for markdown.

It does, and it works reasonably well for developers. Good luck with the average ham wading through a github repo page to find the docs.

>        • Python itself is hosted on GitHub.

This isn't really an argument, right? :)

>        • GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python).

For some definition of easy I guess. Since I'm not a fan of that workflow, I'm biased. However, if you're going to undertake the PyGObject conversion, you can certainly import the repo into github for the collaboration process. But, just like if everything was on github, once you're done I'd expect a sanitized commit history with well-formed commits to come out of that and not just "please merge this branch of 500 messy commits". Unfortunately, that's the way people tend to do stuff in github and I do not think that's a good thing.

>        • Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.

Moving the code and relevant history there is trivial. Even setting up travis to run the tests wouldn't be hard (and arguably would be the major benefit from moving to github in my mind).

Here are other things you didn't cover, which I think are very important:

1. A github repo page is not going to be something the average ham can digest. That means we still need a website for them to land on. It wouldn't make sense to keep using redmine for that, so I/we have to build something else.

2. Related to the above, the docs on the redmine page have to make it to the new page and not just to the github repo.

3. Right now we have code and bugs in the same place. If we move to a github repo, people _will_ file bugs there, but the average ham is not going to be able to create a github account and file bugs there, IMHO. We can't have two places and maintain sanity. I don't know if we can bulk import bug history to github or not, but if we can't then we lose all that history. I can't tell you how many times a week I'm answering direct emails from people working through the very simple process of creating an account on our redmine site so that they can file or comment on a bug. Github makes that not my problem (which might be good), but it also means I don't control it (for helping them) and I think will be more confusing for that level of user, since github is a lot of stuff, not just about chirp. They're very developer-focused, and people are going to be confused about signing up for an account and being presented with their own profile page instead of just going right back to the chirp repo to file their bug.

I would definitely like to have more contributions to chirp, but there will always be more users than developers. Doing what is right by the users is always going to pay off with more adoption, even if it's less desirable for us.

In summary, I'm happy to take contributions for the PyGObject thing if you want to work on it. If you have solutions to the github concerns I have, then I'd be glad to hear them.

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20180609/d9877d0b/attachment-0001.html