[RFC 0015] NixOS Release Managers #15
Conversation
rfcs/0015-release-manager.md
Outdated
| 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 his role, making |
|
No strong opinions on this one |
globin
changed the title
| 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. |
There was a problem hiding this comment.
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.
Note I'm not against it, just wondering what the formalization would bring. EDIT: nevermind
There was a problem hiding this comment.
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.
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.
Nice, I think it's a really good idea. Agreed on not complicating things too much.
| 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.
Is the communication only oral / text or are there written documents that describe the process?
There was a problem hiding this comment.
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.
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.
|
Sounds good to me. |
|
Merging as no objections have been raised. Please make sure to implement the documentation changes! |
Add script for transition
* Various improvements - Remove unnecessary **Description** headers - Rename **Rationale and Alternatives** to just **Alternatives** - Insert must/may/should more diligently - Add some TODOs where things are unclear - Remove numberings from examples when not needed - Minor clarity improvements and simplifications throughout * Apply suggestions from code review Co-authored-by: Ryan Hendrickson <[email protected]> --------- Co-authored-by: Ryan Hendrickson <[email protected]>
* 166: Nix formatting Create 0101-nix-formatting.md WIP Go through a large part and agree on it Co-Authored-By: @piegamesde Update 0101-nix-formatting.md Rework a lot of things Update 0101-nix-formatting.md Move around some sections Reword the detailed section Minor updates Slight header changes again Updates Update 0101-nix-formatting.md Update after today's meeting Update 0101-nix-formatting.md Further updates in the meeting Update 0101-nix-formatting.md After todays meeting Update after meeting Rename to probably the right number Only use anchor links Improvements and additions - The sub-expression rule is now reworded and its own section with examples and rationale - Line length limit is now specified as we agreed-upon in the meeting - The operator section is rewritten to align more with the consensus Redo and explain operator special case Also remove the special case for non-chainable operators, barely any benefit in Nixpkgs * Operator chains outside bindings can also have a compact form * Make the operator compact form specific to binders * Fix accidentally formatted semicolons in alternatives * Minor changes * Light copy editing * Fix .git-blame-ignore-revs * Improve assert/with wording * Be more flexible with single-line element count * binder -> binding * unindent inherit semicolon, reshuffle binding/inherit sections (#14) * unindent inherit semicolon, reshuffle binding/inherit sections * fixup! Stuff * Give alternatives to `in` formatting * Expand on line break preservation * Add editorconfig * Expand argumentation against leading commas * Add @dasJ to the formatter team * Add shepherd team Co-authored-by: Linus Heckemann <[email protected]> * Various improvements (#15) * Various improvements - Remove unnecessary **Description** headers - Rename **Rationale and Alternatives** to just **Alternatives** - Insert must/may/should more diligently - Add some TODOs where things are unclear - Remove numberings from examples when not needed - Minor clarity improvements and simplifications throughout * Apply suggestions from code review Co-authored-by: Ryan Hendrickson <[email protected]> --------- Co-authored-by: Ryan Hendrickson <[email protected]> * Address TODOs and rework with/assert * Minor adjustments * Mention formatting Nix code in documentation * Working towards finalization (#16) - Defined absorption and absorbable terms - Adapted the existing RFC text to make use of these definitions, resulting in simplications of the text in many cases. - Updated `with` section to match the implementation - Updated the function declaration section to match the implementation - Sometimes, the function body may get absorbed - This used to be a special case scoped to bindings only, so it got removed there - Updated the operators section to match the implementation - Specify the format of non-chainable operators (somehow those got lost in the past) - Reworked bindings section. It should now be clear and specific enough. - Minor wording fixes * String section * Specify assert conditions * More absorption for multi-line arguments * How to update the standard format * Fix minor typos * Less lines for common function call patterns * Specify comments * Specify that the formatter should be as pure as possible With some exceptions * nit: fix list concatenation example (#17) * Update rfcs/0166-nix-formatting.md Co-authored-by: Doron Behar <[email protected]> * Add good indentation examples (#18) * Add another chainable operators example * justify difference in semicolon placement * Allow different parenthesized argument style * Clarify non-vertical alignment rule * Improved clarity of bindings rule * Improve bindings semicolon alternatives section --------- Co-authored-by: Silvan Mosberger <[email protected]> Co-authored-by: Silvan Mosberger <[email protected]> Co-authored-by: Ryan Hendrickson <[email protected]> Co-authored-by: Yuriy Taraday <[email protected]> Co-authored-by: Linus Heckemann <[email protected]> Co-authored-by: Janne Heß <[email protected]> Co-authored-by: Doron Behar <[email protected]>
Proposal on NixOS release managers by @fpletz and me.
Rendered: https://github.com/mayflower/nixos-rfcs/blob/release-manager/rfcs/0015-release-manager.md
cc @edolstra @domenkozar @rbvermaa @shlevy @grahamc