| 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 |
> |
Archives