How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
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.63.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.5Please cast your votes,
//arry/
On 13 May 2015 03:47, "Brett Cannon" <brett@python.org> wrote:
On Tue, May 12, 2015 at 1:05 PM Larry Hastings <larry@hastings.org> wrote:
[SNIP]
What do you think? My votes are as follows:
Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5
Please cast your votes,
Workflow 0: -0 Workflow 1: +1 Workflow 2: +0
Workflow 0: -0 Workflow 1: +1 Workflow 2: +0
That's taking into account the clarification that the buildbots will be set up to track the 3.5.x branch after the beta is forked, and that Larry will also push the 3.5rcX repo to hg.python.org for branch testing.
(Possible alternative plan for the latter: rc1 isn't until August, and I could aim to have a pilot Kallithea instance set up by then that uses bugs.python.org credentials to log in. If we didn't get that up and running for some reason, BitBucket could still be a fallback plan)
Cheers, Nick.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
On 05/12/2015 05:19 PM, Nick Coghlan wrote:
Workflow 0: -0 Workflow 1: +1 Workflow 2: +0
That's taking into account the clarification that the buildbots will be set up to track the 3.5.x branch after the beta is forked, and that Larry will also push the 3.5rcX repo to hg.python.org <http://hg.python.org> for branch testing.
I sort of assumed the buildbots would start building the 3.5 branch once it was created, yes. (Are there any branches in the cpython repo that they ignore?)
When you say "branch testing", you mean "running the buildbots against it"? Right now the UI for doing that is pretty clunky. Kicking off a build against a server-side clone (iirc) requires clicking through a couple web pages, filling out a form, and clicking on a teeny-tiny button. It would help *tremendously* here if I could get this automated, so I could run a script locally that made everything happen.
Is there a remote API for starting builds? Or existing automation of any kind? Who should I talk to about this stuff?
(Possible alternative plan for the latter: rc1 isn't until August, and I could aim to have a pilot Kallithea instance set up by then that uses bugs.python.org <http://bugs.python.org> credentials to log in. If we didn't get that up and running for some reason, BitBucket could still be a fallback plan)
I'm happy to consider it. My proposed workflow is only using a very small set of features, and I gather Kallithea already has those features. Bolting on authentication from bugs.python.org would make it *less* friction than using Bitbucket.
But I couldn't say for sure until I got to try it. So get cracking, Nick!
//arry/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 13.05.15 um 09:59 schrieb Larry Hastings:
When you say "branch testing", you mean "running the buildbots against it"? Right now the UI for doing that is pretty clunky. Kicking off a build against a server-side clone (iirc) requires clicking through a couple web pages, filling out a form, and clicking on a teeny-tiny button. It would help *tremendously* here if I could get this automated, so I could run a script locally that made everything happen.
Is there a remote API for starting builds? Or existing automation of any kind? Who should I talk to about this stuff?
Antoine, or me. For branch builds, it would be better to configure them into the buildbot configuration, instead of trying to force them from the outside.
To make this happen, you need to add a repository URL and branch name into the buildbot configuration, and a post-push hook on the repository to trigger the build. It's actually possible to configure a bitbucket POST hook to trigger a buildbot build, but we haven't yet integrated that into the buildbot master.
Regards, Martin
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlVfivYACgkQavBT8H2dyNIzCACdG3yHShN/ZEc1sIiOVYj0lcg0 K9IAnjqLCFN+EewBPLfh651wQUq64nun =0j5m -----END PGP SIGNATURE-----
On May 12, 2015, at 10:04, Larry Hastings <larry@hastings.org> wrote:
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.
One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0.
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.
Where does 3.6.x fit into Workflow 2?
-- Ned Deily nad@acm.org -- []
On 05/12/2015 10:23 AM, Ned Deily wrote:
One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0.
Good point. Though I could concievably push the 3.5.0 rc repo up to an hg.python.org "server-side clone" and kick off the buildbots from there.
Where does 3.6.x fit into Workflow 2?
It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition.
//arry/
On May 12, 2015, at 10:38, Larry Hastings <larry@hastings.org> wrote:
On 05/12/2015 10:23 AM, Ned Deily wrote:
One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. Good point. Though I could concievably push the 3.5.0 rc repo up to an hg.python.org "server-side clone" and kick off the buildbots from there.
I wasn't worrying about the 3.5.0rc "branch", but, yeah, we could probably improvise ones for that as you suggest. So, buildbots would be: 3.5 branch (->3.5.1 as of beta1), 3.5rc (as needed from rc1 to final), along with the current 3.x (->3.5.0 today, -> 3.6.0, as of beta1), 3.4, and 2.7 buildbots.
I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren't able to use Bitbucket, someone could do it for them. In other words, while nice, the use of Bitbucket is not a critical feature of Workflow 1. I think 1 is the best choice with or without the use of Bitbucket. But we should also recognize that adopting it can make more work for committers fixing bugs over the next few months (between beta1 and final), as we need to consider testing and pushing each fix to default (for 3.6.0), 3.5 (for 3.5.0 until rc1, then for 3.5.1), 3.4 (for 3.4.4), and/or 2.7 (for 2.7.11). That's the tradeoff for allowing feature work to be committed, integrated, and tested during the beta and rc periods.
Where does 3.6.x fit into Workflow 2? It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition.
Workflow 0 = -1 Workflow 1 = +1 Workflow 2 = -0.5
-- Ned Deily nad@acm.org -- []
On 05/12/2015 11:21 AM, Ned Deily wrote:
I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren't able to use Bitbucket, someone could do it for them.
For 3.4, I had an amazing number of cherry-picked revisions. By the end it was... 72? over 100? I'm no longer even sure.
Granted, 3.4 had the new module asyncio, and I got a deluge of cherry-pick requests just for that one module. I permitted 'em because a) they wanted it to be ready for prime time when 3.4 shipped, b) there was no installed base, and c) a healthy percentage of those changes were doc-only. (But if Victor tries that again during the 3.5 betas, he may have another thing coming!)
BTW, this workload was exacerbated by my foolish desire to keep the revision DAG nice and clean. So I was actually starting over from scratch and redoing all the cherry-picking every couple of days, just so I could get all the cherry-picked revisions in strict chronological order. By the end I had evolved a pretty elaborate guided-process automation script to do all the cherry-picking, which you can see here if you're curious:
https://hg.python.org/release/file/b7529318e7cc/3.4/threefourtool.pyI have since given up this foolish desire. I'll be happy to have a nice grubby revision DAG if it means I can spend more time on the internet cruising for funny cat videos.
In short, as release manager, I'm pretty stoked by the idea of pressing a big shiny button on a website exactly once when I accept a cherry-pick request.
//arry/
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings <larry@hastings.org> wrote:
BTW, this workload was exacerbated by my foolish desire to keep the revision DAG nice and clean. So I was actually starting over from scratch and redoing all the cherry-picking every couple of days, just so I could get all the cherry-picked revisions in strict chronological order. By the end I had evolved a pretty elaborate guided-process automation script to do all the cherry-picking, which you can see here if you're curious:
Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me.
Cheers,
Dirkjan
On 05/12/2015 05:11 PM, Dirkjan Ochtman wrote:
Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me.
Probably. It's water under the bridge now--that all happened last February and I'm not doing it that way again.
//arry/
On May 12, 2015, at 10:38 AM, Larry Hastings wrote:
It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition.
I still think it's a good idea to focus primarily on 3.5 while it's in the beta/rc period, but if you want to allow for landings on what will be 3.6, then going with workflow 1 will be an interesting social experiment.
I'm fine with any of them as long as the workflow is *well documented*, preferably in the devguide.
Cheers, -Barry
Larry,
On 2015-05-12 1:04 PM, Larry Hastings wrote:
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.
This makes a lot of sense. +1.
Yury
Larry, could you comment about the impact in the buildbots?. I suppose option #1 could allows us to test both 3.5 and 3.6 changes. Would you confirm this?
My votes:
Workflow #0: -0 Workflow #1: +1 Workflow #2: +0
Would be great if we could host the branch for 3.5 ourselves instead of using BitBucket but, at least, it is NOT github :). Competition is good.
-- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
On 05/12/2015 11:18 AM, Jesus Cea wrote:
Larry, could you comment about the impact in the buildbots?. I suppose option #1 could allows us to test both 3.5 and 3.6 changes. Would you confirm this?
Workflow #1 gets us automatic buildbot testing for the 3.5 branch (betas and 3.5.1) and trunk (3.6). It doesn't get us testing of the 3.5.0 release candidates automatically, because those would be hosted at bitbucket. However: hg.python.org allows creating "server-side clones" which can manually run tests against the buildbots. So if I create a server-side clone, then push the release candidate branch there, I can kick off buildbot tests. Who knows, maybe I'd even automate that process.
//arry/
On 05/12/2015 10:04 AM, Larry Hastings wrote:
What do you think? [...] Please cast your votes
workflow 0 1 2
Larry Hastings -0.5 1 0.5 Brett Cannon 0 1 0 Nick Coghlan 0 1 0 Chris Angelico 0 0 0 “in favor of [Workflow 1]” Ned Deily -1 1 -0.5 Barry Warsaw 0 0 0 “I'm fine with any of them as long as the workflow is well documented” Antoine Pitrou -0.5 1 0.5 Ethan Furman 0 1 0 didn't cast explicit votes for anything but workflow 1 Berker Peksag 0 1 0 Yuri Selivanov 0 1 0 didn't cast explicit votes for anything but workflow 1 Jesus Cea 0 1 0
total -2 9 0.5
I'm calling it--the winner by a landslide is the ambitious Workflow 1.
Barry and Chris A didn't cast any explicit votes, but both approved of
Workflow 1. Every other voter was +1 on Workflow 1 and uninterested or
negative on the others.
I'll start experimenting with the workflow(s) and will add documentation to the Dev Guide.
The fun starts next weekend,
//arry/
On Thu, 14 May 2015 07:15:34 -0700, Larry Hastings <larry@hastings.org> wrote:
I'll start experimenting with the workflow(s) and will add documentation to the Dev Guide.
The fun starts next weekend,
By "next weekend" you mean "the weekend after this coming weekend", right? (These calendar idioms always confuse me.)
--David
On 05/14/2015 08:14 AM, R. David Murray wrote:
On Thu, 14 May 2015 07:15:34 -0700, Larry Hastings <larry@hastings.org> wrote:
I'll start experimenting with the workflow(s) and will add documentation to the Dev Guide.
The fun starts next weekend, By "next weekend" you mean "the weekend after this coming weekend", right? (These calendar idioms always confuse me.)
Yes. Python 3.5 beta 1 will be tagged Saturday May 23, for release Sunday May 24.
//arry/
participants (11)
-
"Martin v. Löwis" -
Barry Warsaw -
Berker Peksağ -
Brett Cannon -
Dirkjan Ochtman -
Jesus Cea -
Larry Hastings -
Ned Deily -
Nick Coghlan -
R. David Murray -
Yury Selivanov