| 1 |
El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió: |
| 2 |
[...] |
| 3 |
> > If we want a separate assignee for old stabilizations, what about a |
| 4 |
> > separate project that handles this, or maybe we could assign the bugs |
| 5 |
> > to m-n or something until the arch teams catch up? |
| 6 |
> |
| 7 |
> Again, where is the man power for that? :-) |
| 8 |
> |
| 9 |
> It's the maintainers that this problem hurts most, so they could and |
| 10 |
> should be fixing it themselves - after a few months of waiting, |
| 11 |
> reminding arch teams and gritting your teeth over it, just remove the |
| 12 |
> old stable ebuilds[1]. |
| 13 |
> |
| 14 |
> |
| 15 |
> jer |
| 16 |
> |
| 17 |
> |
| 18 |
> [1] Where possible. If this happens with non-dev, non-experimental |
| 19 |
> architectures and keeping the old ebuilds is a real problem, the |
| 20 |
> architecture's status should be reconsidered. As has been done on |
| 21 |
> this mailing list time and again. If an arch team cannot even be |
| 22 |
> bothered to keep @system up to date, then why bother pretending |
| 23 |
> it's anywhere near "stable"? |
| 24 |
> |
| 25 |
|
| 26 |
I agree with Jeroen here. If the arch teams that are usually a bit |
| 27 |
behind are not able to fix the bugs, I doubt we will gain anything |
| 28 |
assigning bugs to them. Because of the way testing/stabilization bugs |
| 29 |
work, arch teams should always check the bugs with them CCed and, then, |
| 30 |
I don't think getting that bugs assigned to them would change much. |
| 31 |
|
| 32 |
Also, keeping the bugs assigned to package maintainers will still allow |
| 33 |
them to try to get that pending bugs fixed (or resolved in some way) as |
| 34 |
they will take care more about that specific package status. If we get |
| 35 |
that bugs assigned to arch teams, they will likely be ignored by both |
| 36 |
parts, getting worse. |
Archives