As promised the other day, the Python 2/3 porting HOWTO is now live. Yesterday I fixed some things based on feedback from people that I committed today (as well as others contributing their own fixes).
Working on the HOWTO in svn has reminded me how much I prefer hg thanks to all of my work on the devguide. Related to that, I started a branch of the devguide which outlines using hg instead of svn once the transition occurs. I have done all of the easy updates so far, leaving the tough one of outlining a basic workflow which includes back/forward-porting changes.
This whole bit of work stemmed from a massive python-committers thread on the topic. Basically people are trying to decide how best to structure the workflow of python-dev. In svn the way things work is that everything is committed in py3k unless the branch is frozen for cutting a release. If we are in an RC then you have to get approval to commit changes, otherwise you sit on your change until py3k opens up again. As for porting changes between versions, you commit in py3k and then use svnmerge to backport to e.g., release-31maint.
For hg the thinking is to tweak this. It's quite possible that when an RC is reached, a branch will be created that no one but the release manager can touch. When there is a fix in py3k that should be in the RC, the RM (release manager) can cherry-pick the commit and pull it in. While this might seem to create more work for the RM by having them need to execute some cherry-picking command, it does mean they don't need to watch commits that need to be reverted and should also make committers think twice about what they want to bug the RM about.
As for porting, we will most likely switch to a forward-porting strategy. So people would apply a fix in release-31maint and then pull into py3k. The amount of work should be no worse or better than it is with svnmerge, but the DAG from hg should allow for making more sense of what exactly is going on in the history. Plus it makes doing a blanket pull much easier. Also, people will have to make the decision upfront as to whether something needs backporting. Granted, some people might still refuse to put the effort in to backport, but at least for those of us who do it should be at least equal, if not better than, using svnmerge.
But I need to write all of this up and get the resident hg experts to agree on all of this first.
