diff options
authorMatthias Beyer <>2019-04-13 18:33:54 +0200
committerMatthias Beyer <>2019-04-13 18:33:54 +0200
commit6737ad455f5d38e6bfbd94e11556d3d3ff53fcfb (patch)
parent32393e137f01beebdad64567dcb2f627127f8d68 (diff)
Paste first notes
1 files changed, 48 insertions, 7 deletions
diff --git a/rfcs/ b/rfcs/
index f2707da..2a19106 100644
--- a/rfcs/
+++ b/rfcs/
@@ -9,39 +9,80 @@ related-issues: (will contain links to implementation PRs)
# Summary
[summary]: #summary
-One paragraph explanation of the feature.
+Establish a new workflow for changes to the nixpkgs repository. This workflow is
+expected to scale horizontally (more people working with the repository) as well
+as vertically (more "domains" are being worked on / more levels of
+The workflow proposed in this document is inspired by the linux kernel workflow.
# Motivation
[motivation]: #motivation
-Why are we doing this? What use cases does it support? What is the expected
+Pushing to the master branch of a software development project is not a good
+practice in more-than-one-contributor environments.
+Security vulnerabilities, breaking changes which are not tested and regressions
+are easily introduced this way. which could've been prevented by a proper
+<!-- TODO: Expand -->
+In the last year (as of 2019-04-13), we had
+* 17758 commits on the master branch in nixpkgs
+* of which 8551 were merges
+* of which 9207 where non-merge commits
+(use: `git log --oneline --since="1 year ago" --first-parent [--[no-]merges]`)
+This means 48.15% of the commits to master where merges and 51.85% were commits
+which were done directly to the master branch and thus could potentially
+introduce bugs, security vulnerabilities and other changes we do not want in
+By changing our branching workflow to a no-push-to-master workflow, we can
+achieve more security, stability and even more important better scalability.
+<!-- TODO: Expand -->
# Detailed design
[design]: #detailed-design
-This is the bulk of the RFC. Explain the design in enough detail for somebody
-familiar with the ecosystem to understand, and implement. This should get
-into specifics and corner-cases, and include examples of how the feature is
+<!-- TODO -->
# Drawbacks
[drawbacks]: #drawbacks
Why should we *not* do this?
+<!-- TODO -->
+* People are using the right to commit to master, which is their privilege right
+ now and they may not like to give that away.
# Alternatives
[alternatives]: #alternatives
What other designs have been considered? What is the impact of not doing this?
+<!-- TODO -->
+## Impact of not doing this
+We already hit 1.700 pull requests at least once. People are overloaded already.
+This will get worse, which will result in our progress slowing down eventually.
# Unresolved questions
[unresolved]: #unresolved-questions
What parts of the design are still TBD or unknowns?
+<!-- TODO -->
# Future work
[future]: #future-work
What future work, if any, would be implied or impacted by this feature
without being directly part of the work?