| 1 |
On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko <bircoph@g.o> wrote: |
| 2 |
> |
| 3 |
> 2. Otherwise allow developers to drop stable keywords from affected |
| 4 |
> package and _all_ its reverse dependencies. This way a part of |
| 5 |
> stable tree will be removed, but only a part. With this approach |
| 6 |
> arch teams will be freed of an extra burden, while they will be |
| 7 |
> still able to maintain a smaller stable tree. |
| 8 |
> |
| 9 |
> This is a win-win solution: a stable tree will be still kept in a |
| 10 |
> maintainable size and developers will not have a long-term blockers |
| 11 |
> on their stabilization requests. |
| 12 |
> |
| 13 |
> 3. And last but not the least: apply the rules above to all arches, |
| 14 |
> not just minor teams (though probability that amd64/x86 will be |
| 15 |
> slow is lower, of course). |
| 16 |
> |
| 17 |
|
| 18 |
This was some of what I was getting at. My question still stands that |
| 19 |
I'm not sure arch teams REALLY want 300 packages to have their stable |
| 20 |
keywords removed instead of just having one package break the |
| 21 |
depgraph. When we move to git then this won't be as big a deal, as |
| 22 |
they could easily undo all the keywords in the same commit that fixes |
| 23 |
the original STABLEREQ. |
| 24 |
|
| 25 |
I would prefer to get at a more generic policy that can be applied |
| 26 |
everywhere, and not just arch by arch. Being able to keep up or not |
| 27 |
isn't really a black/white thing. Or rather, if it is I think it is |
| 28 |
more a case that nobody can keep up. I think that it would be better |
| 29 |
to have one policy that makes sense on any arch, and as you point out |
| 30 |
it probably won't tend to get applied much to amd64/x86 simply because |
| 31 |
they are better supported. |
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives