Depending on how your process is structured, I can think of two arguments for rotation:

• When we have releases that overlap, such as bug back port releases that happen concurrently with a general release, it helps manage complexity to have separate people handle separate releases.
• Releases often have a “star feature.” In such a case it is very useful to have someone very familiar with that feature be the person who makes the calls on what bugs are show stoppers, what to errata, what last minute changes are too risky, when are we confident it has been sufficiently tested, etc.

There are two things to take into account here.

1. project release process is quite effort consuming:
   • takes 1 month, release manager guide is 15K plain text,
   • has 11 steps featuring total ~50 sub-points (see breakdown below)
2. release is performed by developers (“committers”),
   • they don’t have dedicated release engineer
     ^{guess this is because it’s open source, where everyone wants to be a developer}
   • with process that complicated they’d likely have to also have a backup release engineer

Based on above observations, it’s fairly easy to figure the reasoning behind their claims.

Velocity part of their claim is probably best spelled in release manager guide:

To make a monthly release schedule possible, we spread the burden of releases…

Having one committer doing releases that take as much “burden” as per their guide, plus doing regular development work, would hardly allow them release monthly – more likely two or three times less frequently – and even that would go only until that “only scapegoat committer” doing releases would get bored to death and leave the project.

Stability part of their claim goes most likely from the fact that release process, as well as its documentation are pretty complicated. Rotation of the guys running the process and using the documentation provides permanent review of the process and guide, keeping them up-to-date and in sync.

Appendix: Release manager guide breakdown

I. Preparations During the Month Before a Release
8 sub-points

II. Get the Most Recent Changes
2 sub-points

III. Update the Release Version
10 sub-points

IV. Push Changes to the GitHub Repository
4 sub-points

V. Prepare the Release Tarballs
5 sub-points

VI. Tag the Release Commit
2 sub-points

VII. Push Tarballs to the FTP Server
6 sub-points

VIII. Release Announcement
3 sub-points

IX. Update the Website
7 sub-points

X. Update parrot.github.com and the Relevant parrot-docsx Repository
1 sub-point,…
…plus “more information about the update process”
referring to release_parrot_github_guide.pod which incidentally
contains 4 more sub-points

XI. Publicity
6 sub-points

I think the role of a Release Manager is somewhat different to the role of a Lead Developer, depending on the size of your development team/organisation.

ITIL v3 describes the role of a release manager as:

The Release Manager is responsible for planning and controlling the movement of Releases to test and live environments. His primary objective is to ensure that the integrity of the live environment is protected and that the correct components are released.

The RM is basically accountable and responsible for the following sub-processes:

• Release Management Support
• Release Planning
• Release Build
• Release Deployment
• Early Life Support
• Release Closure

I believe that having strong release management processes and a strong RM can certainly improve project stability, however – I’m not convinced it will improve velocity. There’s also an inherent risk with having one single person responsible for the release management role. As with anything where you have one primary person that knows what to do/what is going on, there needs to be contingency planning in place in the event that person is unavailable or indisposed (e.g. hit by a bus).

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

Having appropriate (and documented) processes and procedures in place and empowering the RM to make decisions, where another person steps into the role they should be able to take up the role with relative ease – providing all processes and practices are transparent. The RM should also be liaising with the Lead Developer for technical advice (where appropriate) before making decisions on the release. This ensures that correct decisions are made based on the information provided by the development team.

The less change we can have to the release process the better from an operational perspective

See my above point, providing the RM is governed by a set of policies and processes that require a change/review process prior to being changed – there shouldn’t be any destabilisation throughout the release process.

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)

This one depends on the culture of the team/organisation. You could have a dedicated team of RMs who rotate through the release cycles and perform other duties when they do not have a “big release” to look after.

Where there is a release that contains complex requirements/features/etc, it would also be a good idea to have someone who knows about these changes as the RM – as they would be best positioned to make decisions about the quality and stability of the code that is to be released. As stated above, having good policies/procedures/documentation about your release process means that the role should not be a far stretch for someone to step into.

When it comes to project velocity, I don’t believe that having a rotating RM will improve it, as having low velocity is generally not because release management practices are bad, or the Release Manager themselves is – it’s usually part of a deeper/wider problem within the development team.

Overall – I think that rotating the role is generally a good idea, as it provides greater transparency to the process and shares knowledge and experience amongst your team members. This means that at any given point, someone should be able to step into the RM role in the event of an “emergency”. Having a backup RM to the currently delegated one should always be in place, just in case that bus comes along and wipes out your RM.