21.05 Call for Release Manager and Release Engineers

Announcements
9

I’m also realizing there’s no “What to do if no one volunteers”. A deadline would probably be useful so everyone can see “this is a pressing matter”.

10

I’m fine with being a solo release manager for a release, but I think it would be helpful for the “health” of NixOS if more people were familiar and involved with the process. I would prefer for someone to volunteer, but don’t consider it critical either.

4 Likes
11

It would be actually dangerous if no one volunteered because the process we have currently works via the exchange of knowledge between two release managers and their collaboration.
That would essentially break what’s in the RFC, and actually considering how easily this could happen I would say it’s a fatal flaw.

The following I could see somehow happening:

  • the aforementioned break in the change of reappointment

  • reappoint each other continuously

we could have a monopoly over the position and be terrible to behold (not that anyone would complain :grin:)

  • appoint people with conflicts of interest

There’s no protections against it. Like idk maybe not appoint two people from the same company.

  • internal disagreement on who the next rm team will

RM B wants person C, but RM A thinks that’s a bad choice. Now we could handle
that like cordially or RM B could just go ahead and announce their appointment and ignore RM A.
RM A could either be quiet about it or have to make a big fuss with no clear way on how to remove both of these people now. (worst case) There’s probably some obvious ways to resolve that effectively.

A good thing currently about the two person team is, one gets incapacitated in some manner everything could possibly still be fine. But beyond that it’s like a novel with a bunch of plot holes. We’d probably have to make it up as we go if conflicts arise. I think the worst process crisis is when there is none, or there’s one but you can’t change it and it sucks. Currently we haven’t had a crisis with this, but we have other process crises like appointing nixpkgs committers and that one’s like having a leaky IV.

With all that in mind, I don’t think in all the releases something terrible like any of those things I mentioned has happened . But as time goes by and we’re building momentum towards making this position better and more people being interested, I think it’s important to analyze these possibilities and consider how this process feels and treats others. The role of an RM after all is to manage risks.

7 Likes
12

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

Relatedly: I’d definitely volunteer as part of the “release team” (considering my discussed-elsewhere “releng” team idea), but I personally don’t think I could take on the mantle of RM.

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

1 Like
13

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

2 Likes
14

I haven’t 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 “put up” with doing a release will likely be a good candidate IMO.

EDIT: You mentioned later this hasn’t 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’t mean I should do a solo release.

Absolutely agree, it’s why the current and my future RFC’s (I’ll be making two more, one for doing a “mini-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.

2 Likes
15

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

1 Like
16

@worldofpeace @domenkozar and I had a meeting earlier today. We would like to announce the creation of the “Release 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 “Release Manager”. Also, since there’s plenty of work which can be done through PRs and PR reviews, these positions are also open to individuals who don’t have commit access.

Release members can be responsible for:

7 Likes
17

Unfortunately, I’m 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 [RFC 0085] NixOS Release Stabilization: ZHF on master, new timeline by jonringer · Pull Request #85 · NixOS/rfcs · GitHub 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
18

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

5 Likes
19

I love this idea! As a non-committer and relative newbie I’m 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.

7 Likes
20

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’s something I have the time and skills for.

1 Like
21

I’d 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’s 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:

4 Likes
22
23

Absolutely, thank you. :slight_smile:

24

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

25

I’ll join the Release Engineering Team. I’m considering the RM role.Can we set up a chat?

7 Likes
26

when zhf is a few weeks out (soon), I’ll probably have two meetings (one for US, one for EU timezone folks). In the meeting I’ll 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’ll probably be the most responsive, but email and discourse I should get back to you under 24 hours

1 Like
27

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

28

Hm, maybe we will have to rename it to something like “Release Engineer”

2 Likes