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.
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 )
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.
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.
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.
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.
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
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.
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).
