| 1 |
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: |
| 2 |
|
| 3 |
> ==Specification== |
| 4 |
> ===Branching model=== |
| 5 |
> The main branch of the Gentoo repository is the <kbd>master</kbd> |
| 6 |
> branch. All Gentoo developers push their work straight to the master |
| 7 |
> branch, provided that the commits meet the minimal quality standards. |
| 8 |
> The master branch is also used straight for continous user repository |
| 9 |
> deployment. |
| 10 |
|
| 11 |
s/continous/continuous/ |
| 12 |
|
| 13 |
> Since multiple developers work on master concurrently, they may be |
| 14 |
> required to rebase multiple times before being able to push. Developers |
| 15 |
> are requested not to use workflows that could prevent others from |
| 16 |
> pushing, e.g. pushing single commits frequently instead of staging them |
| 17 |
> and using a single push. |
| 18 |
|
| 19 |
This is unclear as to which of the two behaviors is encouraged |
| 20 |
vs. discouraged. Maybe just add an an explicit "(encouraged)" and |
| 21 |
"(discouraged)" by each as appropriate? |
| 22 |
|
| 23 |
> Developers can use additional branches to facilitate review and testing |
| 24 |
> of long-term projects of larger scale. However, since git fetches all |
| 25 |
> branches by default, they should be used scarcely. For smaller projects, |
| 26 |
> local branches or repository forks are preferred. |
| 27 |
|
| 28 |
Nit-picking/quibble: |
| 29 |
|
| 30 |
"Can" vs. "may": While "can" is perfectly appropriate as used here in |
| 31 |
informal settings, "may" is more formal (with "can" reserved for whether |
| 32 |
it's technically possible, not at issue here or it wouldn't need mentioned, |
| 33 |
while "may" indicates it's approved/recommended, there's a child's game, |
| 34 |
"Mother may I", that I recall reinforcing this when I was young). |
| 35 |
|
| 36 |
Since this is intended as a GLEP it's arguably quite formal and "may" |
| 37 |
/may/ be more appropriate, thus my mention of the issue altho either |
| 38 |
should be well understood and "can" would be entirely appropriate if the |
| 39 |
context isn't considered quite that formal. |
| 40 |
|
| 41 |
Entirely a judgment call. |
| 42 |
|
| 43 |
> Unless stated otherwise, the rules set by this specification apply to |
| 44 |
> the master branch only. The development branches can use relaxed rules. |
| 45 |
|
| 46 |
Can/may... There may be other uses I won't mention but if you decide |
| 47 |
it's worth changing at all, a search and evaluate usage may be worth it. |
| 48 |
|
| 49 |
> Rewriting history (i.e. force pushes) of the master branch is forbidden. |
| 50 |
|
| 51 |
-- |
| 52 |
Duncan - List replies preferred. No HTML msgs. |
| 53 |
"Every nonfree program has a lord, a master -- |
| 54 |
and if you use the program, he is your master." Richard Stallman |
Archives