Ozone has a philosophy that releases are very important and release managers play a key role.

All developers of Ozone are welcome to be release managers of Ozone.

Being a release manager of Ozone seems easy if you think of it as a set of steps described  in (moved) Ozone Release Guideline.

Generally, life is more complicated, and a guide to Release management is often useful to deal with the unwritten code of release management.

Role of a Release Manager

We choose you for a very important reason. To be the lone voice of reason and put your personal stamp of quality on the release.

We will depend on you to tell us that tests are broken, the tree is degenerating in quality and finally, to shut down all check-ins.  

In short, anything that goes wrong; is your problem, or the buck stops with you.

Most developers are focused on the individual parts of the system, they are not going to look at how long the review queues are,

how many other tests are broken, or if the latest commit has again killed the Apache Spark.2.7 support in Ozone.

You will be the eyes and the screaming voice that guides the release.

What we expect you to do

• Set a date for the release -- Communicate that at the start of the Release Cycle.
• Make a list of features that we are going to ship in the release
• Kick out all sub-projects without mercy, if you think there is the slightest doubt they will not make the release train.
• If the trunk becomes unstable, tests fail, smoke tests do not pass -- raise hell.
• Stop CHECK-INS -- Do that without mercy -- so people are forced to fix issues in the tree. When in doubt -- re-read http://bofh.bjash.com/
• Run smoke tests in the background when you watch a movie, and raise more hell.
• Watch all changes to protobuf files, if you think it is going to kill upgrades -- object, or object anyway and let the developer prove to you that nothing is being broken.
• Cut the branch early that you can stabilize it for the release.
• Cut the branch late that we don’t get into the rebase and backport hell.
• Listen to concerns from all developers, Listen, be sympathetic, and ignore most advice; since most of the asks will only delay the release.
• Make sure that No is the default answer to any request from anybody.
• You will slip, move the release date -- maybe once, maybe twice. After that release date becomes a Joke. Don’t fall into that trap. See earlier advice, kick people out. They are NOT your friends, A release manager has no friends.
• Ignore Architecture Astronauts. All developers have pet projects they love, convince them the next release is the ideal vehicle for them. Just NOT this release.
• Write a post-mortem after release, what went wrong, what went right etc. So others can reflect and learn from you.

List of Release Managers - Past, Present and Future

• 0.2.1 - Release Manager - Marton Elek
• 0.3.0 - Release Manager - Marton Elek
• 0.4.0 - Release Manager - Ajay Kumar
• 0.4.1 - Release Manager - Nanda Kumar
• 0.5.0 - Release Manager - Dinesh Chitlangia
• 0.6.0 - Release Manager - Sammi Chen
• 0.7.0 - Release Manager - Dinesh Chitlangia