Thanks, Martin, for the synopsis.
Thanks, Dan, for the input and discussion.
I created my git repository because I couldn't figure out how to do anything in Matthew's repository. I'm more than willing to abandon my repo.
After updating my copy and creating my repo, I essentially abandoned it myself. I took the latest Chirp from Mercurial, and started checking what was and wasn't working when running Py3. I kinda gave up on that, too.
I started enhancing the GUI to try to bring it up on par with the GTK one, but ran into some really strange issues.
I lost motivation when I asked several questions here in the list, and never got any answers.
Joe Pizzi
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Friday, August 20, 2021 6:51 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Python 3 status
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 _______________________________________________ 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