Here's my take on the current situation with the various efforts at moving Chirp to Python 3.

* Matthew Poletiek has created a GitHub repo for Py3, but it was not created properly. Instead of migrating the Mercurial repo to Git, what Matt did was make a copy / take a snapshot of the 'py3' branch in Mercurial. Then he made some local changes, and *then* he checked it into a new GitHub repo. So there are a couple of issues here. One, all of the history of the codebase has been lost. Two, Matthew's initial changes have been lost, since it looks like he made local changes between copying from Mercurial and checking into GitHub. I suppose, in theory, if you knew the commit at which Matthew made his copy from Mercurial, you could somehow diff the entire tree between that and his initial commit to GitHub. But there's no commit history to explain what he did.

* Joe Pizzi started from Matthew Poletiek's codebase. He too has a repo on GitHub. The big issue here is that, for unknown (to me) reasons, he did not fork Matthew's codebase, preserving history, but actually copied it into a new GitHub repo. So in Joe's codebase, we not only have the same issues as with Matthew's codebase, described above, but we also have the issue of when Joe made his copy of Matthew's codebase, and whether or not Matthew made changes to his after Joe made that copy.

* A huge number of changes have been made to the (Python 2) trunk of Chirp since Matthew made his copy, and those have not been merged into either the 'py3' Mercurial branch or the GitHub tree(s).

This is a mess. It is unclear to me whether Matthew and Joe are intending for their changes to be merged back, but I think it would be extremely unlikely for that to happen. Since the history has been lost in the GitHub trees, any attempt to merge in one or both of these trees would have to come in the form of a gigantic patch with no history. Frankly, I would be very surprised if Dan would apply such a patch, even if he had the time and inclination to review it. Having no opportunity to review the changes commit by commit, it would be an all-or-nothing merge.

In my opinion, what would really need to happen is:

1. 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.)
2. Get that *unmodified* copy pushed up to GitHub as the starting point.
3. Figure out the diff between what Matthew first checked in to his repo and what he copied from Mercurial. If Matthew doesn't have a local Git repo from which to obtain commit info, at least make those changes from the first commit to the new GitHub repo.
4. Figure out whether Matthew has made any changes to his GitHub repo since Joe made his copy. I am not entirely sure what path to take if he has made changes. If he hasn't, then move on.
5. Somehow apply all of the commits from Joe's repo on top of the new GitHub repo, preserving all of the commit history. I've no idea if this is possible given the path that has been taken through the creation of all these trees and commits. I'm also assuming that Joe has made meaningful commits with appropriate explanatory messages, but that may not be a safe assumption.
6. Merge in all of the changes to the trunk in Mercurial since the py3 branch was created (and that have not already been merged; I'm unclear as to whether or not any have). This is a huge task because of the degree of change in the py3 branch and its derivatives.

At that point, there would in theory be a Python 3 version of Chirp in GitHub with full project history. But that is a lot of work, and I've no idea if Matthew and / or Joe would be interested in pursuing it. For someone else to do it without them, the important point in the list above would be #3.


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.

Martin.
KD6YAM