21.05 Call for Release Manager and Release Engineers

Is the 2 RM system set in stone anywhere? I was under the assumption it was, so that there was always one 鈥渘ewbie鈥 per release (as a new set of eyes, as well as to prevent RM burnout by constant rotation).

Relatedly: I鈥檇 definitely volunteer as part of the 鈥渞elease team鈥 (considering my discussed-elsewhere 鈥渞eleng鈥 team idea), but I personally don鈥檛 think I could take on the mantle of RM.

(EDIT: worldofpeace posted just before I finished drafting my thoughts鈥)

1 Like

An RFC even isn鈥檛 stone. It could be amended or replaced. But I evaluate the status quo as is it beneficial or detrimental, and in what ways? I鈥檓 thinking that this RFC as it works currently with two people is just fine, but it鈥檚 lacking details in many ways like I mentioned and it鈥檚 being a bit optimistic of people.


I haven鈥檛 really felt this way about any active member in the community. Maybe I am just naive. Really, anyone who is already active in the community, and willing to 鈥減ut up鈥 with doing a release will likely be a good candidate IMO.

EDIT: You mentioned later this hasn鈥檛 really happened yet, but just being forward about a possible situation.

From a process standpoint, this and process sustainability are the big reasons why I would prefer for someone to stand up. Just because I can do a solo release, doesn鈥檛 mean I should do a solo release.

Absolutely agree, it鈥檚 why the current and my future RFC鈥檚 (I鈥檒l be making two more, one for doing a 鈥渕ini-ZHF鈥 on master between release to remove stale/obsolete/unmaintained packages; and another re-defining how we do stabilization with a more concrete schedule) will be about mitigating the risk going into stabilization.


I鈥檇 suggest that those that are actively merging nixpkgs pick their favorite candidate and ask them to help out :slight_smile:

1 Like

@worldofpeace @domenkozar and I had a meeting earlier today. We would like to announce the creation of the 鈥淩elease Engineering Team鈥.

A release member will coordinate with the release managers and other release members to help aid with the release work. Release members will be able to come and go as they please, so they can participate for just part of the release. This position is really targeted at individuals who may want to play a more active roll in NixOS and aid in a release, but not want to dawn responsibilities of a 鈥淩elease Manager鈥. Also, since there鈥檚 plenty of work which can be done through PRs and PR reviews, these positions are also open to individuals who don鈥檛 have commit access.

Release members can be responsible for:

  • Release items which they can choose to 鈥渙wn鈥
    • Can be stabilizing a package set, suite of related technologies, desktop managers, window managers, etc.
    • E.g. node packages gnome, qt, plasma
    • Can also 鈥渙wn鈥 release blocker items
  • Review or merge ZHF PRs

Unfortunately, I鈥檓 unable to edit the original post, as too much time has gone by. Please refer to the post above for information regarding information about release member responsibilities.

If someone would still like to be the next Release Manager, the position is still vacant. :slight_smile:

With https://github.com/NixOS/rfcs/pull/85 and [RFC 0080] Change NixOS releases to YY.05,YY.11 by jonringer 路 Pull Request #80 路 NixOS/rfcs 路 GitHub the amount of potential headache for a Release Manager should be greatly mitigated. Please re-evaluate if you would like to apply for the position :slight_smile:

1 Like

If this is worth an item on its own, I can take on responsibility for machine learning packages.


I love this idea! As a non-committer and relative newbie I鈥檓 not trusted or qualified to be a full release manager, but I would really like to help out how I can on the release team. I got started making active contributions to Nixpkgs during 20.09 ZHF and I want to learn more about the release process.


Is there a list of things that are up for ownership? Packages or entire families of packages that need attention? Basically asking about a few concrete tasks for the release member role so I can better assess if it鈥檚 something I have the time and skills for.

1 Like

I鈥檇 like to add that this role is an excellent opportunity to get familiar with the Nix ecosystem and community.

@jonringer is now working at IOHK, after being quite active in Nix community and doing the release management.

It鈥檚 important to have good communication skills, as one of the main tasks is to decide how to handle breakages with limited resources and potentially angry users :slight_smile:


Absolutely, thank you. :slight_smile:

I鈥檓 sure we will have something going into a release. However, it鈥檚 a volunteer organization, whatever we are able to get around to, is what we can do.

I鈥檒l join the Release Engineering Team. I鈥檓 considering the RM role.Can we set up a chat?


when zhf is a few weeks out (soon), I鈥檒l probably have two meetings (one for US, one for EU timezone folks). In the meeting I鈥檒l go over the work that is available, and what people would like to contribute; people will be free to pick up as much or as little as they feel comfortable with.

If you want to contact me directly, you can message on discourse, email me, or reach me on discord. Discord I鈥檒l probably be the most responsive, but email and discourse I should get back to you under 24 hours

1 Like

Release Manager and Release Member both abbreviate to RM :wink:

Hm, maybe we will have to rename it to something like 鈥淩elease Engineer鈥


Let鈥檚 do that. Technically anyone can be part of the release by contributing.


It鈥檚 funny that we had a meeting as RMs and now I鈥檓 reappointing myself :grin:
Release items I own would be:

  • GNOME+Pantheon (packages&modules) and ISO鈥檚
  • Everything Freedesktop related (packages&modules)
    鈥 I probably could find more

Might be a tad specific, but I can work on Astronomy/Astrophotography & GPS related packages. Over the last few months I鈥檝e been adding, updating, and patching packages in those domains on master. The astro stuff is generally 鈥渓eaf packages鈥 and their astro specific dependencies. GPS on the other hand can be fairly important since many systems use GPSD for timekeeping and obviously for location/navigation.