[Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

[Larry Hastings]

Python 3.5 beta 1 is coming up soon.  After beta is rc; after rc is 
3.5.0 final.  During the beta and rc periods the Python developer 
workflow changes a little--what sorts of checkins are permissible, and 
how to get something accepted and merged generally becomes more complicated.

I was the release manager for Python 3.4, and the way I ran the rc 
period for 3.4 was miserable.  Everyone hated it--and that includes me.  
I'm absolutely not doing it that way for 3.5.  But that leads one to the 
question: okay, how *am* I going to run it?  I have three ideas for 
workflows for the beta and rc periods for 3.5, below.  But first let's 
talk about what I/we hope to achieve.

Traditionally during the beta and rc periods, development of new 
features stops completely.   Obviously, after feature freeze no new 
features can go into the beta / rc releases.  But why can't people 
develop new features for the *next* release?  The reason given is that 
we're trying to guide the core dev community in the right 
direction--they should concentrate on fixing bugs in the new release.  I 
suspect the real reason for this is that back in the bad old days of 
Subversion (and CVS!) branching and merging were painful.  This social 
engineering policy is a justification after-the-fact.

But Mercurial makes branching and merging nearly effortless. Mercurial 
also makes it painless to develop new features in private.  So consider: 
anyone who wants to work on new features during beta and rc can easily 
do so.  All our "no new features during beta and rc" policy really does 
is drive such development away out of public view.

I think it's time we experimented with lifting that policy.  The trick 
is finding a good place for us to check in the work.  You see, during 
the 3.5 rc period, we arguably want to accept checkins for *three* 
different revisions:

    3.5.0
    3.5.1
    3.6

3.5.1?  Yep.  During the rc period for 3.4--and particularly after the 
last rc was tagged--there were a lot of minor fixes that were desirable, 
but I didn't want to accept into 3.4 just to avoid destabilizing the 
release.  I still wanted those checkins, I just didn't want them in 
3.4.0.  So the way it worked was, developers would check those bugfixes 
in to trunk, then I'd cherry-pick the revisions I wanted into the rc 
branch.  In other words, during the rc period for 3.4, trunk effectively 
represented 3.4.1.  This was valuable and I absolutely want to do it again.


So here are the workflows.  Workflow 0 most resembles what we've done in 
the past.  Workflow 1 is my favorite and the most ambitious.  All three 
give us a public place to put revisions for 3.5.0 and 3.5.1; Workflow 1 
also gives us a place to check in work for 3.6 during the beta and rc 
periods for 3.5.  Workflow 2 is a less ambitious compromise.


Workflow 0
==========

When I ship beta 1, trunk remains 3.5.

When I ship rc 1, trunk becomes 3.5.1.  I create a publically visible 
read-only repo that represents 3.5.0, and any checkins that I want to 
accept into 3.5.0 I must manually cherry-pick from trunk.

When I ship Python 3.5.0 final, we branch 3.5, and trunk becomes 3.6.

Workflow 1
==========

When I ship beta 1, we create the 3.5 branch.  trunk become 3.6.

When I ship rc 1, the 3.5 branch becomes 3.5.1.  I maintain a publically 
visible repo /on bitbucket/ for 3.5.0, and we use bitbucket "pull 
requests" for cherry-picks from 3.5.1 into 3.5.0.

This gives us a pilot project to try out a web GUI for merging.  It 
makes my workflow easier, as I can push a button to accept 
cherry-picks.  (If they don't apply cleanly I can tell the author to go 
fix the conflict and resubmit it.)  The downside: it requires core devs 
to have and use bitbucket accounts.

Workflow 2
==========

When I ship beta 1, trunk remains 3.5.

When I ship rc 1, we create the 3.5 branch.  The 3.5 branch is 3.5.0 and 
trunk is 3.5.1.  Only blessed stuff gets cherry-picked from 3.5.1 back 
into 3.5.0.


What do you think?  My votes are as follows:

    Workflow 0: -0.5
    Workflow 1: +1
    Workflow 2: +0.5


Please cast your votes,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150512/20cab77b/attachment.html>