[chirp_devel] Modernizing

[Derek Chauran]

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

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.

  1.  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.
  2.  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). Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...)
  3.  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. Of course, there is also a mercurial plugin that allows mercurial users to work against GitHub repos: https://bitbucket.org/durin42/hg-git/overview
[https://d301sr5gafysq2.cloudfront.net/a6f25d658c68/img/repo-avatars/default.png]<https://bitbucket.org/durin42/hg-git/overview>

durin42 / hg-git — Bitbucket<https://bitbucket.org/durin42/hg-git/overview>
This is the Hg-Git plugin for Mercurial, adding the ability to push and pull to/from a Git server repository from Hg. This means you can collaborate on Git based projects from Hg, or use a Git server as a collaboration point for a team with developers using both Git and Hg. The Hg-Git plugin can ...
bitbucket.org


  4.  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.
  5.  Github comes with its own documentation/hosting system with native support for markdown.
  6.  Python itself is hosted on GitHub.
  7.  GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python).
  8.  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.

Anyhow, I'd love to hear what other people's thoughts are on this. I don't want to go down a path that will be outright rejected 😊

Thanks,
Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20180608/22b8260e/attachment-0001.html