On Sun, 16 Feb 2014 14:50:41 -0600 William Hubbs <[email protected]> wrote:
> On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote: > > On Sun, 16 Feb 2014 09:41:03 +0100 > > Pacho Ramos <[email protected]> wrote: > > > > > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió: > > > [...] > > > > > If we want a separate assignee for old stabilizations, what > > > > > about a separate project that handles this, or maybe we could > > > > > assign the bugs to m-n or something until the arch teams > > > > > catch up? > > > > > > > > Again, where is the man power for that? :-) > > > > > > > > It's the maintainers that this problem hurts most, so they > > > > could and should be fixing it themselves - after a few months > > > > of waiting, reminding arch teams and gritting your teeth over > > > > it, just remove the old stable ebuilds[1]. > > > > > > > > > > > > jer > > > > > > > > > > > > [1] Where possible. If this happens with non-dev, > > > > non-experimental architectures and keeping the old ebuilds is a > > > > real problem, the architecture's status should be reconsidered. > > > > As has been done on this mailing list time and again. If an > > > > arch team cannot even be bothered to keep @system up to date, > > > > then why bother pretending it's anywhere near "stable"? > > > > > > > > > > I agree with Jeroen here. If the arch teams that are usually a bit > > > behind are not able to fix the bugs, I doubt we will gain anything > > > assigning bugs to them. Because of the way testing/stabilization > > > bugs work, arch teams should always check the bugs with them CCed > > > and, then, I don't think getting that bugs assigned to them would > > > change much. > > > > That would be true if the context of this thread were the arch team; > > however, the context of this thread is the maintainer as that is the > > person experiencing the problem that was put forward. > > > > The solution here thus intends to address the maintainer, which > > benefits from this; while it keeps the arch team's the same, > > whether the arch team does more with this is their own > > responsibility. > > > > > Also, keeping the bugs assigned to package maintainers will still > > > allow them to try to get that pending bugs fixed (or resolved in > > > some way) as they will take care more about that specific package > > > status. > > > > Package maintainers have better things to do. While it would allow > > for example the GNOME team to maintain GNOME 2 which sticks around; > > it actually happening is another story as they want to see GNOME 2 > > go, because maintaining multiple versions of GNOME costs too much > > time. > > > > > If we get that bugs assigned to arch teams, they will likely be > > > ignored by both parts, getting worse. > > > > At this point the arch team can realize that keeping the version > > around is an unrealistic goal, they can then take a decision to > > stop keeping it around and thus remove it; if needed, taking > > additional steps. > > You are still assuming that the arch team is fully staffed. If they > are not, the old versions of packages still remain in the tree > indefinitely. It allows undermanned arch teams to prioritize; and as a consequence of that, the assumption is that arch team's are undermanned as the fully staffed arch teams benefit less from this. This is under the assumption that this is being put to good use by the arch team, but that's up to them; as I mentioned yesterday this is focused more on the maintainer. Ignoring this, I see what you are getting at in the second part of that paragraph; it indeed could become annoying to have to track which versions you are and no longer are maintaining, which adds another parameter of complexity to our daily maintenance work. > As a maintainer, at some point, I don't want them around. > > Keeping them around can force me to keep old migration code for > example that automates upgrading to new versions longer than I would > have to otherwise. +1 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
