On Sun, 16 Feb 2014 00:37:03 +0100
Jeroen Roovers <[email protected]> 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).

In this case the maintainer isn't needed on the bug anymore.

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

The music seems unfit for the situation, how does this apply here?

> > 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? :-)

The lack of manpower is a given by this thread, it's more about relief.

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

Exactly, it's that simple; but, it will be reverted per policy. 

> [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"?

What "stable" means is really suffering from manpower; to be optimal it
would mean the most thorough review you can possibly think of, on top
of that the state of the ebuild is monitored a long time afterwards.

However, some do simple compile tests up to the point that the word no
longer adds stabilization on top of that of upstream and maintainer;
but rather acts to confirm that it has been made to compile, after
which the question is whether the effort will become a waste of time.

Stabilization requires tons of manpower to really work; the only way to
get that to happen with high efficiency and effectivity is to bring a
lot more people to the table, and let it also be done by the users that
already have interest in running ~ on their systems.

As they say, the more eyes the better.

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

Reply via email to