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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com