-
-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC 0015] NixOS Release Managers #15
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,79 @@ | ||
--- | ||
feature: release-manager-nixos | ||
start-date: 2017-07-18 | ||
author: Robin Gloster (@globin) | ||
co-authors: Franz Pletz (@fpletz) | ||
related-issues: -- | ||
--- | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
NixOS currently has no process for electing release managers (RMs). We propose to | ||
switch to a model with two RMs, where each RM SHOULD | ||
serve for a consecutive term of two releases. A new RM is appointed | ||
by the previous team for each new release. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
Currently release managing in NixOS has mostly been done by individuals who | ||
volunteered and were then chosen by the last release manager. Over the last | ||
few releases a process has been established and | ||
[documented](https://nixos.org/nixos/manual/index.html#release-process). | ||
As this makes it easier to cut a release this role should be passed on | ||
regularly and not be held by a single individual over a longer time. | ||
|
||
# Detailed design | ||
[design]: #detailed-design | ||
|
||
For each release there are two RMs. After each release the RM having | ||
managed two releases steps down and the RM team of the last release | ||
appoint a new RM. | ||
|
||
This makes sure a RM team always consists of one RM who already has | ||
managed one release and one RM being introduced to their role, making | ||
it easier to pass on knowledge and experience. | ||
|
||
A release manager's role is mostly facilitating: | ||
* manage the release process | ||
* start discussions about features and changes for a given release | ||
* create a roadmap | ||
* release in cooperation with Eelco Dolstra | ||
* decide which bug fixes, features etc. get backported after a release | ||
|
||
The process outlined in this RFC has informally started by @globin taking | ||
over the role from @domenkozar for NixOS 17.03 and having the latter as a | ||
backup and contact at all times for questions and support. We propose to | ||
continue this by appointing @fpletz for the second RM, who has been working | ||
with @globin a lot to keep the additional overhead of communication to a | ||
minimum at the beginning. | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
There is more communicational overhead but by having a second RM | ||
two individuals are checking the issues from a RM's point of view. | ||
Additionally it ensures that there is always one | ||
RM with the experience of having released NixOS once before. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the communication only oral / text or are there written documents that describe the process? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The release process is roughly documented in the NixOS manual: https://nixos.org/nixos/manual/index.html#release-process There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nice. I think that would be the perfect place to insert the election system proposed in this RFC as well. Maybe we can add a note saying that it's the responsibility of the release manager to maintain that section of the documentation. |
||
|
||
# Alternatives | ||
[alternatives]: #alternatives | ||
|
||
We can consider continuing the process as is and not specifying it formally, | ||
this will probably continue to work but does not ensure the role being passed | ||
on regularly. | ||
|
||
There are other possibilities how a RM can be elected, by vote (who by?), by | ||
@edolstra, RFCs, etc. This would mean even more overhead and the need of | ||
defining eligibility to vote or centring more decisions around @edolstra. | ||
|
||
# Unresolved questions | ||
[unresolved]: #unresolved-questions | ||
|
||
Nothing we can currently think of. | ||
|
||
# Future work | ||
[future]: #future-work | ||
|
||
* Specifying the process for releasing NixOS itself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What problem does it solve? Is it hard to find a release manager, is there too much demand, ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note I'm not against it, just wondering what the formalization would bring.EDIT: nevermindThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from influence you also make sure that knowledge spreads. If one person keeps a role for a long time, they may not document it as well because its not relevant for others. Furthermore, it may improve connectivity with the community if it is seen that such role isn't limited to "just a few".
These are some potential arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, when we thought of this we had @FRidh's arguments in mind. I think there can always be small deviations from the rule if necessary. For instance, if a release manager can't continue her duties due to illness or other unforeseen circumstances, other people like preferably previous release mangers should be able to take over. We didn't want to specify this in detail but only give a rough proposal how the position should be filled. The important thing for us is that we have a new release manager for every release and a previous release manager for support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I think it's a really good idea. Agreed on not complicating things too much.