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.