| 1 |
On 5/8/16 7:25 AM, Andreas K. Hüttel wrote: |
| 2 |
> Am Sonntag, 8. Mai 2016, 01:52:22 schrieb Patrice Clement: |
| 3 |
>> |
| 4 |
>> What is the correct course of action? I would very much like it to be |
| 5 |
>> worded in a document (GLEP and/or Wiki page) so that confusion is avoided |
| 6 |
>> and we all are on the same page on this topic. |
| 7 |
>> |
| 8 |
> |
| 9 |
> * However... as the past months have shown, when using merges it is much |
| 10 |
> easier to accidentally mess up the entire tree than using rebases alone. |
| 11 |
> |
| 12 |
> * So, in an ideal world we would use merges wisely and sparingly. |
| 13 |
|
| 14 |
Correct. I don't support outright banning merge commits, but they |
| 15 |
should be reviewed carefully, like we do with other big commits to the |
| 16 |
tree. So maybe proceed as follows: |
| 17 |
|
| 18 |
1. announce to gentoo-dev@ the intention to start a branch intending to |
| 19 |
merge |
| 20 |
|
| 21 |
2. hack hack hack |
| 22 |
|
| 23 |
3. test the merge for any conflicts etc, |
| 24 |
|
| 25 |
4. announce to the list a date/time to merge |
| 26 |
|
| 27 |
5. if okay, ermge |
| 28 |
|
| 29 |
> |
| 30 |
> * In the real world, we risk less and also lose less if we ban and technically |
| 31 |
> prevent them. |
| 32 |
> |
| 33 |
> * The only alternative would be to come up with criteria for merges and |
| 34 |
> actually enforce them (meaning, if you mess up the tree more than twice you |
| 35 |
> lose your push access. Hello QA.). |
| 36 |
> |
| 37 |
|
| 38 |
|
| 39 |
-- |
| 40 |
Anthony G. Basile, Ph.D. |
| 41 |
Gentoo Linux Developer [Hardened] |
| 42 |
E-Mail : blueness@g.o |
| 43 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 44 |
GnuPG ID : F52D4BBA |
Archives