| 1 |
On 04/06/15 06:54, Rich Freeman wrote: |
| 2 |
> On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@g.o> wrote: |
| 3 |
>> |
| 4 |
>> 2. Otherwise allow developers to drop stable keywords from affected |
| 5 |
>> package and _all_ its reverse dependencies. This way a part of |
| 6 |
>> stable tree will be removed, but only a part. With this approach |
| 7 |
>> arch teams will be freed of an extra burden, while they will be |
| 8 |
>> still able to maintain a smaller stable tree. |
| 9 |
>> |
| 10 |
>> This is a win-win solution: a stable tree will be still kept in a |
| 11 |
>> maintainable size and developers will not have a long-term blockers |
| 12 |
>> on their stabilization requests. |
| 13 |
>> |
| 14 |
>> 3. And last but not the least: apply the rules above to all arches, |
| 15 |
>> not just minor teams (though probability that amd64/x86 will be |
| 16 |
>> slow is lower, of course). |
| 17 |
>> |
| 18 |
> |
| 19 |
> This was some of what I was getting at. My question still stands that |
| 20 |
> I'm not sure arch teams REALLY want 300 packages to have their stable |
| 21 |
> keywords removed instead of just having one package break the |
| 22 |
> depgraph. When we move to git then this won't be as big a deal, as |
| 23 |
> they could easily undo all the keywords in the same commit that fixes |
| 24 |
> the original STABLEREQ. |
| 25 |
|
| 26 |
I strongly prefer removing stable keywords of all reverse dependencies |
| 27 |
over random 'transient' breakage that won't be fixed in a reasonable |
| 28 |
timeframe (we're starting from the assumption that the relevant arch |
| 29 |
team didn't respond in *months* ...) |
| 30 |
|
| 31 |
How git is relevant I don't really see, you'd still have to re-test all |
| 32 |
involved packages, so the effort is mostly in testing and not in running |
| 33 |
ekeyword in a loop. |
| 34 |
|
| 35 |
Have fun, |
| 36 |
|
| 37 |
Patrick |
Archives