Hello again, with 20.09 and the retrospective complete, development on unstable never stops here in NixOS.
We will be needing a new release manager for 21.05 and 21.11 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 myself or @worldofpeace.
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 are always 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. Although it’s never been an explicit requirement before, 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. I will be improving the release documentation to include a time table so the release process is more predictable on someone’s schedule.
In general the responsibilities are:
Create release roadmap
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
As mentioned in What should stable NixOS prioritize? - #2 by jonringer, I will attempt to push back the release date to YY.05 and YY.11 through an RFC to help with desktop manager packaging pain. So the 21.03 release may be 21.05.
The release schedule is now 21.05 and 21.11
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 would be curious to hear more about your estimates @jonringer from an hourly contribution (weekly or total) you suspect you put into release management.
I was considering it, however you are very very active and it was not always easy to tell if that was just typical contributions or release managerial duties.
I was going to re-vamp the release docs, and it should give a pretty detailed schedule of the events. And you can read the tasks ahead-of-time. Usually the biggest “time-sinkers” are just trying to communicate with other NixOS members or teams.
That’s fair. I did 105 commits and 400+ reviews in November. But recently, I feel like @Sandro has taken the “most active” crown. We went from ~2700 open PRs to <2500 open PRs in the week or so that he got commit access xD
The story behind the name is really boring. My old nick was already taken when I registered an account on YouTube and back then they suggested nicknames and Super Sandro2000 was on off them.
I do not plan to be as active as I am right now all the time. Everyone needs breaks and when the global pandemic is over I plan to start again with other hobbies which are very important to me.
To get back to topic: I thought about applying here but I am not sure if I am a good fit. I am not that long with the project, I don’t know much about nixos modules and regularly skip PRs about them and I am not even running NixOS anywhere. On the other hand I run Nix on Debian, WSL and Darwin where I got pretty knowledgeable in the last months, I review a lot of PRs and try to stabilize things as much as possible while still merging quite fast.
I qualify for all the requirements and I think I would be a half decent fit for this so I would like to apply for it if everyone is okay with it.
@worldofpeace and I would like to see some sort of “release team” which could help with the burden of trying to stabilize. Whether or how this would be implemented is still up to debate, but it would be nice to have someone focused on GNOME, one on Plasma, just reviewing PRs, or help with a few other ecosystems. The NixOS community is pretty active, so people will help in various ways, but generally the efforts are disorganized. I like to refer to the NixOS community as a “herd of technical cats”.
Anyway, I hope that my RFCs (second one I’m still preparing) will help with making the releases a lot less stressful for everyone. I think everyone who has contributed to NixOS is invested in some way, and we all want to see it succeed.
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”.
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.
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 )
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.
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…)
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.
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.
@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:
Release items which they can choose to “own”
Can be stabilizing a package set, suite of related technologies, desktop managers, window managers, etc.
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.
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.
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.
)