1 |
On Mon, Oct 19, 2015 at 1:55 PM, hasufell <hasufell@g.o> wrote: |
2 |
> On 10/19/2015 07:52 PM, Rich Freeman wrote: |
3 |
>> On Mon, Oct 19, 2015 at 1:40 PM, hasufell <hasufell@g.o> wrote: |
4 |
>>> On 10/19/2015 07:37 PM, Rich Freeman wrote: |
5 |
>>>> |
6 |
>>>> However, stabilizing a single package really is an impactful change. |
7 |
>>>> The fact that you're doing 100 of them at one time doesn't really |
8 |
>>>> diminish the impact of each one. Any of them could break a system or |
9 |
>>>> need to be reverted. |
10 |
>>>> |
11 |
>>> |
12 |
>>> Since when do we allow reverting stabilization? The package needs to be |
13 |
>>> fixed and possibly revbumped instead. |
14 |
>>> |
15 |
>> |
16 |
>> It would really depend on the nature of the break. If it is a serious |
17 |
>> upstream problem and no fix is available, then reverting might be the |
18 |
>> only practical solution. It is of course not a preferred solution. |
19 |
>> |
20 |
> |
21 |
> I don't think we depend on 'git revert' in that case. KEYWORDS are |
22 |
> trivial changes (in terms of file diffs). |
23 |
> |
24 |
|
25 |
True, as long as they're truly standalone. |
26 |
|
27 |
Maybe the compromise is: |
28 |
1. Groups of related stabilizations should be grouped. |
29 |
2. Groups of only unrelated stabilizations can also be grouped. |
30 |
3. You must not try to mix #1 and #2 in the same commit. |
31 |
|
32 |
As you say individual packages are easy to revert anyway. However, we |
33 |
wouldn't want 100 of those to be mixed in with 50 packages that all |
34 |
needed to be coordinated, because those 50 aren't easy to revert. |
35 |
|
36 |
-- |
37 |
Rich |