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


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.

  • And before anyone mentions that the claim has a [citation needed] notice, I added it ;) – yannis Aug 7 '12 at 4:36

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.
  • I'd add the same argument for rotating tech leads: it's largely a thankless job, and rotating its responsibilities is a way to share the burden and prevent one person from burning out. – MebAlone Sep 2 '12 at 20:29

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.