21.11 Call for Release Manager

21.11 Call for Release Manager

We will be needing a new release manager for 21.11 and 22.05 release; you will need to work in co-operation with NixOS contributors, myself, and Eelco Dolstra. The release process in NixOS is in a time of great change, so this is the perfect moment for someone who really wants to leave their mark.
If you are interested, please get in contact with me.

Contact Info

Github handle Matrix ID
jonringer @jonringer:matrix.org

I (@jonringer) am also on the community discord server, if you DM there, I’ll get a notification directly to my phone

Why do we need a release manager? What to expect

Being a release manager in NixOS is not a solitary experience.
There should always be two release managers, where each release manager serves
for two consecutive terms/releases. With each new release the previous team gets to
appoint a new manager. (what’s happening right now). This way, you always have the guidance of a release manager who has the experience of releasing NixOS before. See the RFC for more details. As mentioned, releasing NixOS is in a time of change, expect the ability to improve it within our means.
Being a release manager means you will have greater impact to the NixOS community, and develop greater insight into the community as a whole. You can also view this as an opportunity to acquire some project management skills as well.
Expect it to be transformative.

Qualifications

  • Commit Access to Nixos/Nixpkgs . A good portion of the work of a release manager is to review changes going into the release branch. And, some of the release tasks will require you to push directly to the repository.

Responsibilities

Outside of ZHF, the “workload” is minimal, however, the month leading up to the expected release date will have a few periods where you may need to set time aside to complete release management tasks. The release process is now detailed on a dedicated wiki, thanks to @worldofpeace for doing the majority of the wiki work.

In general the responsibilities are:

  • Track blocking issues
  • Review PRs ( other committers well aide you with this )
  • Conduct stabilization (ZHF)
  • Perform release management task, listed here
  • Coordinate with other release manager about tasks
    • You will want to be able to contact the manager on a semi-regular basis.

Related Changes

The RFC for stabilization has been accepted, the new release timeline is now reflected in the release wiki.

Impact

Having a stable release goes a long way to allowing commercial adoption of Nixpkgs and NixOS. For the long-term future of NixOS, these releases are crucial to its success.

I hope to hear from all of you. :slight_smile:

11 Likes

As a member of the community for several years now, I’d like to be the first to offer myself up for the position. It would be a great learning opportunity, and I’d be happy for the chance to make more meaningful contributions to the NixOS ecosystem. Of course, if someone with a bit more tenure would like a shot, that’s fine too. :slightly_smiling_face:

12 Likes

I can volunteer and dedicate time to be a Release Manager.

16 Likes

I’m thinking of bringing in another release manager, as it’s pretty consistent that life obligations tend to appear around release time. It’s hard to know your availability a year in advance.

4 Likes

Not that I want to be a candidate, but just for clarity, what does ZHF stands for?

1 Like

ZHF stands for Zero Hydra Failures, a focused effort to minimize the number of errors and failures in preparation for a release. The linked wiki is pretty good at explaining the details.

2 Likes

Fantastic news! You’re such an asset to this community not only through your technical contributions but your extreme efforts to mentor community members. I’m so glad you volunteered. Thanks for all your hardwork and commitment to the project @tomberek :heart:

3 Likes

Wait… a year in advance? 21.11 work starts within weeks, right? (22.05 is closer to a year, yes) Or was there some typo?

1 Like

Since release managers do two release cycles, there’s about a 8-10 month window (depending on when the call first went out) to the second release, I rounded up to a year. I think the immediate release is usually easier for people to have clarity about obligations, but it’s very possible to have a kid (or other large obligation arise) between the first and second release (like what happened to @disassembler).

So yes, I was referring to the 22.05 release. :slight_smile:

With the RFC changes around release, I feel like it was a lot less stressful (at least for myself). Hopefully this will carry over to the future releases.

As for coordination of release activity between many release managers, I think the bulk of the work is reviewing PRs, and that’s easily parallelize-able. The actual release tasks usually only a few minutes per week (but are usually blocked by larger work).

6 Likes