Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Date: Tue, 21 Jan 2014 00:46:44
Message-Id: CAGfcS_=of0GG2fLrzkvsApmrW9UkVNG7akg_q8MeV9N6eLYHvQ@mail.gmail.com
In Reply to: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights by Patrick Lauer
1 On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer <patrick@g.o> wrote:
2 >
3 > Yey, we're allowed to sometimes do revert games, if we're asking nicely
4 > ... and the only way to stop the revert game is for QA to stand down.
5 > We're allowed to send strongly-worded emails, but getting things baked
6 > into policy is too radical.
7
8 So, here is how I reconcile this. There are basically two kinds of
9 problems - technical problems, and people problems. We need to deal
10 with both. I see QA as being primarily responsible for technical
11 problems, and it should be staffed to deal with them. I'm fully
12 supportive of it being a policy-creating body, with the Council being
13 the place to vet any policies that seem controversial.
14
15 If an ebuild has a deficiency, that's a technical problem - QA should
16 step in. QA should also educate the maintainer so that they
17 understand how to avoid the problem in the future.
18
19 Suppose the maintainer refuses to take the problem seriously (whether
20 they're just lazy, incompetent, or malicious). Now, that is a people
21 problem, and really shouldn't be QA's responsibility to deal with
22 beyond pointing it out to Comrel.
23
24 Comrel should deal with people problems, and they should be staffed
25 accordingly. They need the manpower so that they can deal with them
26 efficiently. When QA says that a developer is not following a
27 technical policy, Comrel should defer to them as this is their area of
28 expertise. If either QA or Comrel gets out of hand there is always
29 the appeal to Council, so neither body needs to be walking on
30 eggshells or taking 18 months to decide to do something about a
31 problem. If QA feels like Comrel isn't taking their complaints
32 seriously, there is the Council - Comrel should be taking their
33 concerns seriously. However, QA needs to recognize that people
34 problems aren't always best solved with the use of command-line
35 utilities.
36
37 In then end we'll only get where we need to be if we work together,
38 and avoid the passive-aggressive nonsense. If somebody feels that QA
39 is out of line by all means put it on the Council agenda. Otherwise,
40 devs need to do what they can to make the job of QA easier, and not
41 harder.
42
43 About the only time I really see need for "emergency suspension
44 powers" is in the situation of some kind of hacking attempt. I'm not
45 aware of any attack like this ever being mounted, but if it were the
46 necessary action would involve a lot more than just suspending
47 somebody's commit rights. Probably the best first action would be to
48 disable all rsync/etc distribution, lock down cvs entirely, and then
49 begin cleanup.
50
51 If there is some kind of general standing problem of Comrel ignoring
52 QA by all means let the Council know (assuming you can't just work it
53 out with them). However, Comrel announced not all that long ago a
54 general desire to enforce CoC with short bans/etc, and that they were
55 interested in having a vital QA organization so that they have some
56 kind of authority to rely on for technical questions. That certainly
57 sounds like a good direction to me, so I don't want to dwell too much
58 on the past.
59
60 Bottom line - don't be afraid to do your job, and when something gets
61 in the way speak up about it!
62
63 Rich

Replies

Subject Author
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights Alec Warner <antarus@g.o>