The Wikipedia article on Parrot VM includes this unreferenced claim:
Core committers take turns producing releases in a revolving schedule, where no single committer is responsible for multiple releases in a row. This practice has improved the project's velocity and stability.
Parrot's Release Manager role documentation doesn't offer any further insight into the process, and I couldn't find any reference for the claim. My first thoughts were that rotating release managers seems like a good idea, sharing the responsibility between as many people as possible, and having a certain degree of polyphony in releases.
Is it, though? Rotating release managers has been proposed for Launchpad, and there were some interesting counterarguments:
Release management is something that requires a good understanding of
all parts of the code and the authority to make calls under pressure if
issues come up during the release itself
The less change we can have to the release process the better from an
operational perspective
Don't really want an engineer to have to learn all this stuff on the
job as well as have other things to take care of (regular development
responsibilities)
Any change of timezones of the releases would need to be approved with
the SAs
and:
I think this would be a great idea (mainly because of my lust for
power), but I also think that there should be some way making sure that
a release manager doesn't get overwhelmed if something disastrous
happens during release week, maybe by have a deputy release manager at
the same time (maybe just falling back to Francis or Kiko would be
sufficient).
The practice doesn't appear to be very common, and the counterarguments seem reasonalbe and convincing. I'm quite confused on how it would improve a project's velocity and stability, is there something I'm missing, or is this just a bad edit on the Wikipedia article?
Worth noting that the top voted answer in the related "Is rotating the lead developer a good or bad idea?" question boldly notes:
Don't rotate.
