Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: jer@g.o
Cc: gentoo-dev@l.g.o
Subject: Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)
Date: Sun, 16 Feb 2014 08:00:32
Message-Id: 20140216090016.052f7116@TOMWIJ-GENTOO
In Reply to: Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords) by Jeroen Roovers
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

Replies