1 |
On Sun, 16 Feb 2014 14:50:41 -0600 |
2 |
William Hubbs <williamh@g.o> wrote: |
3 |
|
4 |
> On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote: |
5 |
> > On Sun, 16 Feb 2014 09:41:03 +0100 |
6 |
> > Pacho Ramos <pacho@g.o> wrote: |
7 |
> > |
8 |
> > > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió: |
9 |
> > > [...] |
10 |
> > > > > If we want a separate assignee for old stabilizations, what |
11 |
> > > > > about a separate project that handles this, or maybe we could |
12 |
> > > > > assign the bugs to m-n or something until the arch teams |
13 |
> > > > > catch up? |
14 |
> > > > |
15 |
> > > > Again, where is the man power for that? :-) |
16 |
> > > > |
17 |
> > > > It's the maintainers that this problem hurts most, so they |
18 |
> > > > could and should be fixing it themselves - after a few months |
19 |
> > > > of waiting, reminding arch teams and gritting your teeth over |
20 |
> > > > it, just remove the old stable ebuilds[1]. |
21 |
> > > > |
22 |
> > > > |
23 |
> > > > jer |
24 |
> > > > |
25 |
> > > > |
26 |
> > > > [1] Where possible. If this happens with non-dev, |
27 |
> > > > non-experimental architectures and keeping the old ebuilds is a |
28 |
> > > > real problem, the architecture's status should be reconsidered. |
29 |
> > > > As has been done on this mailing list time and again. If an |
30 |
> > > > arch team cannot even be bothered to keep @system up to date, |
31 |
> > > > then why bother pretending it's anywhere near "stable"? |
32 |
> > > > |
33 |
> > > |
34 |
> > > I agree with Jeroen here. If the arch teams that are usually a bit |
35 |
> > > behind are not able to fix the bugs, I doubt we will gain anything |
36 |
> > > assigning bugs to them. Because of the way testing/stabilization |
37 |
> > > bugs work, arch teams should always check the bugs with them CCed |
38 |
> > > and, then, I don't think getting that bugs assigned to them would |
39 |
> > > change much. |
40 |
> > |
41 |
> > That would be true if the context of this thread were the arch team; |
42 |
> > however, the context of this thread is the maintainer as that is the |
43 |
> > person experiencing the problem that was put forward. |
44 |
> > |
45 |
> > The solution here thus intends to address the maintainer, which |
46 |
> > benefits from this; while it keeps the arch team's the same, |
47 |
> > whether the arch team does more with this is their own |
48 |
> > responsibility. |
49 |
> > |
50 |
> > > Also, keeping the bugs assigned to package maintainers will still |
51 |
> > > allow them to try to get that pending bugs fixed (or resolved in |
52 |
> > > some way) as they will take care more about that specific package |
53 |
> > > status. |
54 |
> > |
55 |
> > Package maintainers have better things to do. While it would allow |
56 |
> > for example the GNOME team to maintain GNOME 2 which sticks around; |
57 |
> > it actually happening is another story as they want to see GNOME 2 |
58 |
> > go, because maintaining multiple versions of GNOME costs too much |
59 |
> > time. |
60 |
> > |
61 |
> > > If we get that bugs assigned to arch teams, they will likely be |
62 |
> > > ignored by both parts, getting worse. |
63 |
> > |
64 |
> > At this point the arch team can realize that keeping the version |
65 |
> > around is an unrealistic goal, they can then take a decision to |
66 |
> > stop keeping it around and thus remove it; if needed, taking |
67 |
> > additional steps. |
68 |
> |
69 |
> You are still assuming that the arch team is fully staffed. If they |
70 |
> are not, the old versions of packages still remain in the tree |
71 |
> indefinitely. |
72 |
|
73 |
It allows undermanned arch teams to prioritize; and as a consequence of |
74 |
that, the assumption is that arch team's are undermanned as the fully |
75 |
staffed arch teams benefit less from this. This is under the assumption |
76 |
that this is being put to good use by the arch team, but that's up to |
77 |
them; as I mentioned yesterday this is focused more on the maintainer. |
78 |
|
79 |
Ignoring this, I see what you are getting at in the second part of |
80 |
that paragraph; it indeed could become annoying to have to track which |
81 |
versions you are and no longer are maintaining, which adds another |
82 |
parameter of complexity to our daily maintenance work. |
83 |
|
84 |
> As a maintainer, at some point, I don't want them around. |
85 |
> |
86 |
> Keeping them around can force me to keep old migration code for |
87 |
> example that automates upgrading to new versions longer than I would |
88 |
> have to otherwise. |
89 |
|
90 |
+1 |
91 |
|
92 |
-- |
93 |
With kind regards, |
94 |
|
95 |
Tom Wijsman (TomWij) |
96 |
Gentoo Developer |
97 |
|
98 |
E-mail address : TomWij@g.o |
99 |
GPG Public Key : 6D34E57D |
100 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |