1 |
What about just at first giving QA the authority to unilaterally revert |
2 |
commits in the event they cause QA violations? |
3 |
|
4 |
Assuming that a QA violation is clear and evident, it seems reasonable to |
5 |
allow it to be reverted immediately without further need for deliberation, |
6 |
since introducing a QA violation could be construed as a regression. |
7 |
|
8 |
If this is done it has the immediate benefit of prompt limitation of damage |
9 |
and goes directly towards what I think is QA's mission. |
10 |
|
11 |
I'm assuming it's implied that an erroneous revert is itself actionable as |
12 |
dereliction of duty by QA. |
13 |
|
14 |
Letting QA handle the immediate task of protecting/maintaining quality |
15 |
standards in the ebuild tree seems the right move. |
16 |
|
17 |
Whether the offending developer should face disciplinary action for |
18 |
violating QA in the first place IMO should be a separate issue. |
19 |
|
20 |
A possible idea is to let QA make a referral to proctors and/or comrel as |
21 |
necessary. For example, for the offending developer's actual QA violation |
22 |
a warning might be issued by proctors. A developer who shows a pattern of |
23 |
negligence, or who deliberately overrides a QA revert, or otherwise |
24 |
aggravates the situation beyond a proctor-level concern could be referred |
25 |
to comrel. |
26 |
|
27 |
The general idea is to let QA take preemptive action as necessary to |
28 |
protect or undo any damage caused by a QA violation, since the tree itself |
29 |
needs protection that may well not benefit from waiting for social |
30 |
procedures involving discipline, and have any disciplinary matters handled |
31 |
as a separate issue possibly with a referral to proctors/comrel. |
32 |
|
33 |
But the gist is having discipline treated as a separate issue that can be |
34 |
handled with social procedures and break off the actual QA task so that the |
35 |
tree's integrity doesn't wait for deliberation. |
36 |
|
37 |
On Fri, Apr 26, 2019 at 6:21 PM Chí-Thanh Christopher Nguyễn < |
38 |
chithanh@g.o> wrote: |
39 |
|
40 |
> Alexis Ballier schrieb: |
41 |
> |
42 |
> > I would add maximum amounts of time everywhere here: For the QA ban |
43 |
> > because this effectively still leaves room for "age of the universe" |
44 |
> > long bans and a slightly shorter one for the comrel response to ensure |
45 |
> > no important ban is missed due to people being on vacations. |
46 |
> |
47 |
> If we agree that QA bans are emergency powers *only* to avert breakage |
48 |
> reaching users, and/or causing unreasonable amounts of work for other |
49 |
> developers to undo, then that would implicitly limit the time of a ban to |
50 |
> whenever the next ComRel/Council meeting can discuss this incident. |
51 |
> |
52 |
> Afterwards it will either be lifted or turned into a ComRel ban. |
53 |
> |
54 |
> > Depending on that maximum, council appeal may not be needed because |
55 |
> > it'd take longer than the ban length anyway. |
56 |
> |
57 |
> I think that ComRel review of the QA emergency decision should be the |
58 |
> default |
59 |
> unless the disciplinary action has expired or was lifted in the meantime. |
60 |
> |
61 |
> But even so, if some QA decision is questionable, bringing it before |
62 |
> Council |
63 |
> is good irrespective of whether it is a past or current matter. |
64 |
> |
65 |
> |
66 |
> Best regards, |
67 |
> Chí-Thanh Christopher Nguyễn |
68 |
> |
69 |
> |