diff options
author | Matthias Beyer <mail@beyermatthias.de> | 2019-04-13 18:33:54 +0200 |
---|---|---|
committer | Matthias Beyer <mail@beyermatthias.de> | 2019-04-13 18:33:54 +0200 |
commit | 6737ad455f5d38e6bfbd94e11556d3d3ff53fcfb (patch) | |
tree | e20886ac0ab0f100283abae2e658af4d6ebe1900 /rfcs/0043-nixpkgs-workflow.md | |
parent | 32393e137f01beebdad64567dcb2f627127f8d68 (diff) |
Paste first notes
Diffstat (limited to 'rfcs/0043-nixpkgs-workflow.md')
-rw-r--r-- | rfcs/0043-nixpkgs-workflow.md | 55 |
1 files changed, 48 insertions, 7 deletions
diff --git a/rfcs/0043-nixpkgs-workflow.md b/rfcs/0043-nixpkgs-workflow.md index f2707da..2a19106 100644 --- a/rfcs/0043-nixpkgs-workflow.md +++ b/rfcs/0043-nixpkgs-workflow.md @@ -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 +responsibility). + +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 -outcome? +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 +workflow. +<!-- 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 +nixpkgs. + +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 -used. +<!-- 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? + |