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.py

I 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