In my opinion, what would really need to happen is:
- Do a proper migration of the Mercurial codebase to Git, preserving full history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.)
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.
For completeness, the other alternative is to start again, from the Chirp trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
This is easy to say, but it's just not that simple. We can't stop chirp development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people. Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.
I spent a ton of time working on the py3 stuff for a while, but pretty much burned myself out on it. When the flatpak stuff came it became harder and harder to justify the extra work because it's easy for most linux users to just use. The apple silicon thing is obviously a problem, but they're a smaller group than linux users. Since the python2 stuff is still installable by PPA, it's just really difficult for me to justify working on it. I know it's a looming problem.
If there was someone committed to bringing the new py3 GUI up to parity with the current one at least, that would help incentivize me to work on publishing builds from that other branch and keeping the other branch synced up. If we got to the point where the GUI was reasonably close, and most/all of the drivers worked, then obviously switching over and abandoning the python2 branch would be the thing to do. However, lots of people show up here with big plans, but it rarely pans out :/
I definitely agree that the various trees that have sprung up with no history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.
--Dan