1 |
On Sun, 16 Feb 2014 09:41:03 +0100 |
2 |
Pacho Ramos <pacho@g.o> wrote: |
3 |
|
4 |
> El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió: |
5 |
> [...] |
6 |
> > > If we want a separate assignee for old stabilizations, what about |
7 |
> > > a separate project that handles this, or maybe we could assign |
8 |
> > > the bugs to m-n or something until the arch teams catch up? |
9 |
> > |
10 |
> > Again, where is the man power for that? :-) |
11 |
> > |
12 |
> > It's the maintainers that this problem hurts most, so they could and |
13 |
> > should be fixing it themselves - after a few months of waiting, |
14 |
> > reminding arch teams and gritting your teeth over it, just remove |
15 |
> > the old stable ebuilds[1]. |
16 |
> > |
17 |
> > |
18 |
> > jer |
19 |
> > |
20 |
> > |
21 |
> > [1] Where possible. If this happens with non-dev, non-experimental |
22 |
> > architectures and keeping the old ebuilds is a real problem, the |
23 |
> > architecture's status should be reconsidered. As has been done |
24 |
> > on this mailing list time and again. If an arch team cannot even be |
25 |
> > bothered to keep @system up to date, then why bother pretending |
26 |
> > it's anywhere near "stable"? |
27 |
> > |
28 |
> |
29 |
> I agree with Jeroen here. If the arch teams that are usually a bit |
30 |
> behind are not able to fix the bugs, I doubt we will gain anything |
31 |
> assigning bugs to them. Because of the way testing/stabilization bugs |
32 |
> work, arch teams should always check the bugs with them CCed and, |
33 |
> then, I don't think getting that bugs assigned to them would change |
34 |
> much. |
35 |
|
36 |
That would be true if the context of this thread were the arch team; |
37 |
however, the context of this thread is the maintainer as that is the |
38 |
person experiencing the problem that was put forward. |
39 |
|
40 |
The solution here thus intends to address the maintainer, which benefits |
41 |
from this; while it keeps the arch team's the same, whether the arch |
42 |
team does more with this is their own responsibility. |
43 |
|
44 |
> Also, keeping the bugs assigned to package maintainers will still |
45 |
> allow them to try to get that pending bugs fixed (or resolved in some |
46 |
> way) as they will take care more about that specific package status. |
47 |
|
48 |
Package maintainers have better things to do. While it would allow |
49 |
for example the GNOME team to maintain GNOME 2 which sticks around; it |
50 |
actually happening is another story as they want to see GNOME 2 go, |
51 |
because maintaining multiple versions of GNOME costs too much time. |
52 |
|
53 |
> If we get that bugs assigned to arch teams, they will likely be |
54 |
> ignored by both parts, getting worse. |
55 |
|
56 |
At this point the arch team can realize that keeping the version around |
57 |
is an unrealistic goal, they can then take a decision to stop keeping |
58 |
it around and thus remove it; if needed, taking additional steps. |
59 |
|
60 |
-- |
61 |
With kind regards, |
62 |
|
63 |
Tom Wijsman (TomWij) |
64 |
Gentoo Developer |
65 |
|
66 |
E-mail address : TomWij@g.o |
67 |
GPG Public Key : 6D34E57D |
68 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |