1 |
On Sun, 16 Feb 2014 00:37:03 +0100 |
2 |
Jeroen Roovers <jer@g.o> wrote: |
3 |
|
4 |
> On Sat, 15 Feb 2014 16:53:22 -0600 |
5 |
> William Hubbs <williamh@g.o> wrote: |
6 |
> |
7 |
> > The problem with this is, what if it is more than one arch team? |
8 |
> > Which one do you assign it to? |
9 |
> |
10 |
> Oh the fun we had in the past when bugs got assigned to one arch team |
11 |
> with a few others CC'd and no maintainer in sight (because maybe the |
12 |
> maintainer was the reporter, or was blanky assumed to be known). |
13 |
|
14 |
In this case the maintainer isn't needed on the bug anymore. |
15 |
|
16 |
> Or when another arch alias got CC'd later on. Or when a maintainer got |
17 |
> fed up waiting and reassigned to an arch team in a "rage quit". And |
18 |
> so on. It makes very messy bug reports. Musical chairs, anyone? |
19 |
|
20 |
The music seems unfit for the situation, how does this apply here? |
21 |
|
22 |
> > If we want a separate assignee for old stabilizations, what about a |
23 |
> > separate project that handles this, or maybe we could assign the |
24 |
> > bugs to m-n or something until the arch teams catch up? |
25 |
> |
26 |
> Again, where is the man power for that? :-) |
27 |
|
28 |
The lack of manpower is a given by this thread, it's more about relief. |
29 |
|
30 |
> It's the maintainers that this problem hurts most, so they could and |
31 |
> should be fixing it themselves - after a few months of waiting, |
32 |
> reminding arch teams and gritting your teeth over it, just remove the |
33 |
> old stable ebuilds[1]. |
34 |
|
35 |
Exactly, it's that simple; but, it will be reverted per policy. |
36 |
|
37 |
> [1] Where possible. If this happens with non-dev, non-experimental |
38 |
> architectures and keeping the old ebuilds is a real problem, the |
39 |
> architecture's status should be reconsidered. As has been done on |
40 |
> this mailing list time and again. If an arch team cannot even be |
41 |
> bothered to keep @system up to date, then why bother pretending |
42 |
> it's anywhere near "stable"? |
43 |
|
44 |
What "stable" means is really suffering from manpower; to be optimal it |
45 |
would mean the most thorough review you can possibly think of, on top |
46 |
of that the state of the ebuild is monitored a long time afterwards. |
47 |
|
48 |
However, some do simple compile tests up to the point that the word no |
49 |
longer adds stabilization on top of that of upstream and maintainer; |
50 |
but rather acts to confirm that it has been made to compile, after |
51 |
which the question is whether the effort will become a waste of time. |
52 |
|
53 |
Stabilization requires tons of manpower to really work; the only way to |
54 |
get that to happen with high efficiency and effectivity is to bring a |
55 |
lot more people to the table, and let it also be done by the users that |
56 |
already have interest in running ~ on their systems. |
57 |
|
58 |
As they say, the more eyes the better. |
59 |
|
60 |
-- |
61 |
With kind regards, |
62 |
|
63 |
Tom Wijsman (TomWij) |
64 |
Gentoo Developer |
65 |
|
66 |
E-mail address : TomWij@g.o |
67 |
GPG Public Key : 6D34E57D |
68 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |