| ... |
... |
@@ -11,29 +11,13 @@ Any major feature additions should be raised as a proposal on the `Mailing List |
|
11
|
11
|
|
|
12
|
12
|
The author of any patch is expected to take ownership of that code and is to support it for a reasonable time-frame. This means addressing any unforeseen side effects and quirks the feature may have introduced. More on this below in 'Granting Committer Access'.
|
|
13
|
13
|
|
|
14
|
|
-Granting Committer Access
|
|
15
|
|
--------------------------
|
|
16
|
|
-
|
|
17
|
|
-We'll hand out commit access to anyone who has successfully landed a single patch to the code base. Please request this via irc or the mailing list.
|
|
18
|
|
-
|
|
19
|
|
-This of course relies on contributors being responsive and show willingness to address problems after landing branches there should not be any problems here.
|
|
20
|
|
-
|
|
21
|
|
-What we are expecting of committers here in general is basically to
|
|
22
|
|
-escalate the review in cases of uncertainty:
|
|
23
|
|
-
|
|
24
|
|
-* If the patch/branch is very trivial (obvious few line changes or typos etc), and you are confident of the change, there is no need for review.
|
|
25
|
|
-
|
|
26
|
|
-* If the patch/branch is non trivial, please obtain a review from another committer who is familiar with the area which the branch effects. An approval from someone who is not the patch author will be needed before any merge.
|
|
27
|
|
-
|
|
28
|
|
-We don't have any detailed policy for "bad actors", but will of course handle things on a case by case basis - commit access should not result in commit wars or be used as a tool to subvert the project when disagreements arise, such incidents (if any) would surely lead to temporary suspension of commit rights.
|
|
29
|
|
-
|
|
30
|
14
|
Patch Submissions
|
|
31
|
15
|
-----------------
|
|
32
|
16
|
|
|
33
|
17
|
We will be running `trunk based development <https://trunkbaseddevelopment.com>`_. The idea behind this is that merge requests to the trunk will be small and made often, thus making the review and merge process as fast as possible. We do not want to end up with a huge backlog of outstanding merge requests. If possible,
|
|
34
|
18
|
it is preferred that merge requests address specific points and clearly outline what problem they are solving.
|
|
35
|
19
|
|
|
36
|
|
-Branches must be submitted as merge requests on gitlab and should be associated with an issue report on gitlab, whenever possible. If it's a tiny change, we'll accept an MR without it being associated to a gitlab issue, but generally we strongly prefer an issue to be raised in advance. This is so that we can track the work that is currently in progress on the project - please see our Gitlab policy below.
|
|
|
20
|
+Branches must be submitted as merge requests on gitlab and should be associated with an issue report on gitlab, whenever possible. If it's a small change, we'll accept an MR without it being associated to a gitlab issue, but generally we prefer an issue to be raised in advance. This is so that we can track the work that is currently in progress on the project - please see our Gitlab policy below.
|
|
37
|
21
|
|
|
38
|
22
|
Each commit should address a specific gitlab issue number in the commit message. This is really important for provenance reasons.
|
|
39
|
23
|
|
| ... |
... |
@@ -113,6 +97,21 @@ Remember that with python, the modules (python files) are also symbols |
|
113
|
97
|
within their containing *package*, as such; modules which are entirely
|
|
114
|
98
|
private to BuildGrid are named as such, e.g. ``_roy.py``.
|
|
115
|
99
|
|
|
|
100
|
+Granting Committer Access
|
|
|
101
|
+-------------------------
|
|
|
102
|
+
|
|
|
103
|
+We'll hand out commit access to anyone who has successfully landed a single patch to the code base. Please request this via irc or the mailing list.
|
|
|
104
|
+
|
|
|
105
|
+This of course relies on contributors being responsive and show willingness to address problems after landing branches there should not be any problems here.
|
|
|
106
|
+
|
|
|
107
|
+What we are expecting of committers here in general is basically to
|
|
|
108
|
+escalate the review in cases of uncertainty:
|
|
|
109
|
+
|
|
|
110
|
+* If the patch/branch is very trivial (obvious few line changes or typos etc), and you are confident of the change, there is no need for review.
|
|
|
111
|
+
|
|
|
112
|
+* If the patch/branch is non trivial, please obtain a review from another committer who is familiar with the area which the branch effects. An approval from someone who is not the patch author will be needed before any merge.
|
|
|
113
|
+
|
|
|
114
|
+We don't have any detailed policy for "bad actors", but will of course handle things on a case by case basis - commit access should not result in commit wars or be used as a tool to subvert the project when disagreements arise, such incidents (if any) would surely lead to temporary suspension of commit rights.
|
|
116
|
115
|
|
|
117
|
116
|
BuildGrid policy for use of Gitlab features
|
|
118
|
117
|
-------------------------------------------
|
