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. -- 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
