On 05/12/2015 11:21 AM, Ned Deily
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:
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.