Derek:

It's really awesome that you (and others) have been discussing/considering such improvements. I also feel that CHIRP is a super valuable tool with a friendly and savvy community which is why I keep on reading the devel list and try to promote CHIRP to others whenever I can. I am ashamed to admit that my personal todo list items related to CHIRP have been ignored for a while now due to time and other pressures, however, your proposal is getting my creative juices flowing.

Python2 is, technically, EOL in a mere 1.5 years and I'm pretty sure my own scripts are likely going to still need updating by then given all my other distractions. I like the idea of incremental improvements to move to Python3 even without considering any of the fancier GUI stuff. Although, kivy might be a neat add-on later too. It might be fun to fight with more Python2-to-3 migrations after work too :)

I know there used to be a dedicated CHIRP CLI tool at one point but I'm not certain what happened to it. Such things would be really handy while trying to update half a dozen radios at one sitting, say, a couple days before a weekend thing-a-thon when somebody adds a new repeater and I'm too lazy and/or busy packing to fuss around with clicking on things to update them all again. An API would be pretty slick.

I have often wished to use my usual git tools, workflow and feature branches while working on CHIRP things--it would likely have made it easier in the past for me to find some time in-between other tasks to work on stuff. Using the hg-git backend would be very nice and would also allow others to retain their hg tools, workflow and so on as well. I do not want to add any additional burden to Dan's life either so I will understand if such a drastic backend change doesn't get implemented anytime soon.

The patch process works alright but it does mean that I don't tend to rebase very often or work on a lot of different issues at the same time and it does also mean that I can't easily share feature branches between my home computer and work computer. It's not hg's fault, it's mine (probably)--I've been using git daily for over a decade so it's a bit hard for me to go back to doing things with patch.

I have maintained my own git clone of CHIRP using git-hg (not to be confused with hg-git) to provide a more convenient interface for browsing stuff, however, this clone isn't sustainable for long term use as the commit IDs aren't deterministric unless the hg-git backend is used so I treat my clone more as a disposable thing.

I like most of the added features of GitHub and the convenient pull-request review interface but, as it's all just git underneath, it does make it fairly easy to push another copy to GitLab and/or Bitbucket for when the borg eventually comes to assimilate all your private repos. I really don't care whether it's hosted on GitHub, GitLab, Bitbucket, Gitosis or whatever; Just that I can use the same git command-line stuff to let me browse the history and keep track of my junk that's still in progress.

So, in short, I like where you're going with this and I will try to help. I do hope that some of your proposed changes might help improve my velocity when trying to do refactors in CHIRP. I would also really love to be able to learn by doing with the help of code review comments and perhaps have some more directed and interactive sessions collaborating on a refactor rather than just letting my private feature branches languish on my machine.

Thanks and 73,

Tyler VA3DGN

On 08/06/18 03:00 PM, chirp_devel-request@intrepid.danplanet.com wrote:

Message: 1 Date: Fri, 8 Jun 2018 08:44:20 +0000 From: Derek Chauran af7ux@outlook.com Subject: [chirp_devel] Modernizing To: "chirp_devel@intrepid.danplanet.com" chirp_devel@intrepid.danplanet.com Message-ID: MWHPR13MB0896ACF6D5270D897D27668EE1670@MWHPR13MB0896.namprd13.prod.outlook.com

Content-Type: text/plain; charset="utf-8"

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....]https://bitbucket.org/durin42/hg-git/overview

durin42 / hg-git ? Bitbuckethttps://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