[chirp_devel] Modernizing

Fri Jun 8 20:36:13 PDT 2018

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 at intrepid.danplanet.com wrote:
> Message: 1
> Date: Fri, 8 Jun 2018 08:44:20 +0000
> From: Derek Chauran <af7ux at outlook.com>
> Subject: [chirp_devel] Modernizing
> To: "chirp_devel at intrepid.danplanet.com"
> 	<chirp_devel at intrepid.danplanet.com>
> Message-ID:
> 	<MWHPR13MB0896ACF6D5270D897D27668EE1670 at 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.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
> 
> ------------------------------
> 
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> 
> 
> End of chirp_devel Digest, Vol 86, Issue 5
> ******************************************
> 