On Sat, 15 Feb 2014 19:05:56 -0600 William Hubbs <[email protected]> wrote:
> On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote: > > On Sat, 15 Feb 2014 16:53:22 -0600 > > William Hubbs <[email protected]> wrote: > > > > > The problem with this is, what if it is more than one arch team? > > > Which one do you assign it to? > > > > Oh the fun we had in the past when bugs got assigned to one arch > > team with a few others CC'd and no maintainer in sight (because > > maybe the maintainer was the reporter, or was blanky assumed to be > > known). Or when another arch alias got CC'd later on. Or when a > > maintainer got fed up waiting and reassigned to an arch team in a > > "rage quit". And so on. It makes very messy bug reports. Musical > > chairs, anyone? > > > > > 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? :-) > > Agreed, I was just trying to find a middle ground to satisfy the other > side of this. You've already did that with the very first post of your thread; this question however can be interpreted as either the given or the problem, I'd prefer the former as the latter would make this thread something that wouldn't have taken place. > > 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]. > > Agreed, all the way. this is a real problem for package maintainers > when arch teams are so understaffed they can't keep up. > > Also, it does a disservice to our users for us to claim we have stable > trees on these arches when the stable packages are multiple versions > behind the maintainer's stable requests. +1, on top of that it is further behind what upstream considers stable; alongside that comes the drop in upstream support and bug filing, as the old version could be considered unsupported by upstream. -- 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
