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. > 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. William > 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"? >
signature.asc
Description: Digital signature
