Since I have asked about github in the past as well, thought I should chime in. Regarding workflow, PR, and commenting.I actually like this compared to hg, patchbomb. I think the discussion, review, and signoff can be handled much better (and with better history tracking). You can tie some change on a line of code back to the commit, and back to the pr, and the captured discussion behind it. With the current flow, the discussion happens passively in email, and you would have to dig through mailing list archive to follow the discussion and see the approvers behind it.With git hub code reviews, you can designate certain folks as reviewers to give a thumbs up for the change. https://help.github.com/articles/requesting-a-pull-request-review/You can also see all of the integrated testing run against a proposed change in a PR build, and require that to pass before it can even be committed. (While you might be doing this now, it's up front, obvious, and for all to see who are part of the PR.)https://help.github.com/articles/defining-the-mergeability-of-pull-requests/ Regarding the documentation thing. Markdown and readmes are great for commenting the repo itself for developers, but for general user documentation there are two great resources. Github wiki. Much like the existing danplanet one, it's pretty easy to edit and maintain E.g. https://github.com/Netflix/Hystrix/wiki Github pages. Many projects will take their project page up one notch, and can be hosted on github.io. Some examples:https://github.com/collections/github-pages-examples This could be the "landing page" which average users land on, e.g. "chirp.github.com" Regarding the messy commits thing.It doesn't have to be a thing. If you don't want to keep a messy commit history two things:1. use contributing guidelines to explain to prospective contributors what you expect (PEP8 & style stuff, required pre-commit testing, review process, commits structure, etc)2. squash merge - or just explain that in #2 to contributors to squash their working branch into a new clean, merge-worthy branch before opening pr, such that it's already donehttps://help.github.com/articles/about-pull-request-merges/#squash-and-merge...
I think in general moving to github is about making contributing more accessible, and about making all of the peripheral activities more visible and traceable. While contribute to the codebase infrequently, I would be willing to help as much as I can with any effort to migrate the repo/testing/etc over to github.(I'm a repo admin for a number of orgs and repos at my work, and CI/CD stuff is part of my duties as well.) -Jens AF5MI
On Saturday, June 9, 2018, 10:25:48 AM CDT, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
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 _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers