1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
---
feature: nixpkgs-workflow
start-date: (fill me in with today's date, YYYY-MM-DD)
author: Matthias Beyer (@matthiasbeyer)
co-authors: (find a buddy later to help our with the RFC)
related-issues: (will contain links to implementation PRs)
---
# Summary
[summary]: #summary
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
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. Those can been prevented by a proper workflow
and tooling that comes with the 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
## Entities
Before we get to the details of the design proposed in this RFC, we define the
entities used in the workflow.
Those are:
* "Aspect": Either a (sub)set of packages, services or other infrastructure
which is related to or exists in the nixpkgs repository.
* "Team": a limited group of people which is responsible for one _aspect_ of the
nixpkgs repository.
* "Core Contributor": A person belonging to one or more Teams.
* "Contributor": A person who _actively_ contributes to the nixpkgs repository,
possibly maintains packages and can be considered _known_ (in person or by
nick) in the community.
* "External Contributor": A person that does not belong to any team, and is not
(yet) known to the community.
## Workflow description
The following section describes the workflow.
### Top-Level Workflow
<!-- TODO: Better wording for header -->
### Team workflow
### Contributor workflow
### External Contributor workflow
<!--
TODO: Describe how external contributors should be routed to the right
repository
-->
## Implementation
<!-- TODO: How to get there -->
### CONTRIBUTING.md
<!-- TODO: How to rewrite the contributing guide -->
<!-- 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?
|
