Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] January 2014 QA Policy Updates
Date: Fri, 31 Jan 2014 06:14:30
In Reply to: Re: [gentoo-dev] January 2014 QA Policy Updates by Peter Stuge
1 On Thu, Jan 30, 2014 at 9:48 PM, Peter Stuge <peter@×××××.se> wrote:
3 > Chris Reffett wrote:
4 > > - -The QA team policymaking workflow will look like the following:
5 > ..
6 > > If we think a developer's actions are causing problems, we may ask
7 > > them to stop/undo pending discussion by the QA team at the next meeting.
8 >
9 > plus
10 >
11 > > - -Rules for the QA team editing peoples' packages:
12 > ..
13 > > *For trivial fixes, such as repoman errors, we fix the issue and send
14 > > the developer a friendly reminder
15 > > *For large but non-critical fixes, we open a bug, wait 2 weeks, and if
16 > > it is not fixed within that time frame we make the change.
17 >
18 > sounds to me like QA is giving itself carte blanche to make any "fix"
19 > they want as per "we think a developer's actions are causing problems"
20 > hmm?
21 >
23 To be fair, I had a long discussion with this regarding when QA has the
24 authority to temporarily ban a developer. This discussion came about
25 because on occasion, a developer and the QA team will have a disagreement
26 regarding a package, and QA will attempt to assert their authority. My
27 interpretation is that the authority of the QA team nominally comes from
28 the idea that we want a certain level of quality in the tree, and that we
29 have policies in place to facilitate that quality level.
31 So in a case where a developer is clearly violating an existing documented
32 policy, then QA does have the authority to modify their package after a
33 short discussion about it. In the case where policy is missing, QA does not
34 have a clear case of authority there. It becomes a more murky area. I've
35 tried to very much encourage QA to both publish the policies they want to
36 enforce, and automate enforcement with better tooling (repoman or
37 otherwise). Being transparent and consistent in enforcement of policy goes
38 a long way for getting developers on your side.
40 So in short, while one could read that passage as you did, I don't think
41 that is their intention. When developers 'cause problems' it should be
42 obvious to everyone how and why that is, and not simply obvious to
43 say...the QA lead.
45 -A
48 >
49 >
50 > //Peter
51 >
52 >


Subject Author
Re: [gentoo-dev] January 2014 QA Policy Updates Rich Freeman <rich0@g.o>
Re: [gentoo-dev] January 2014 QA Policy Updates Peter Stuge <peter@×××××.se>