From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AF3A6138334 for ; Sat, 27 Apr 2019 01:48:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 239CBE0867; Sat, 27 Apr 2019 01:48:14 +0000 (UTC) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B866DE0866 for ; Sat, 27 Apr 2019 01:48:13 +0000 (UTC) Received: by mail-ot1-x335.google.com with SMTP id t20so4246037otl.5 for ; Fri, 26 Apr 2019 18:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GR5LEugFchqZe/BP5OiOZcCmpD3bFiVg9epeBj7uhdg=; b=cS42ttG8u7pyZ5YEvxSJ+/mEH4AdNvl8s6EwMECuB/4E70TUbHT2Y+5D8/dp5StVYL HSYMGZ2Z/oD4rcqHnDMYIIsCQhJNXoQ1kLIsp68rYrDn0p2byX+MQ1xdbRIhLRXFTwf8 dVwX0TLkgdW36b0GX4CW/fbdS8jzfo+JnTU8LFVe55LUGrRI52swgAKyoZEIXG8+jjiE O3PxmBTo7ktfiRmTpLk66pP4EDkAIOINIKKIGJRT0SeeOgG6qEBR8Xctp+Lkf72Kn56a +vMSZSB6rLkoDYKzYpSE9zYEg/0t3gzVzjKeKIsmzXpuHAbg5pz3iJq7YAa4xl2ameSL 5G8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GR5LEugFchqZe/BP5OiOZcCmpD3bFiVg9epeBj7uhdg=; b=CetWYaG55Hujad18EJm+tjZTZdI4CQINxqAC3CCIf0UZ0HnW6X2+Fayjezm0+9AGD9 j7PIuKsi3Qd4PiDCyWHg+7hX5ja/Tkk+e9Rgj61xUcOKt+ouq22i0rciieciUolyS2qg FCp/oZsI1DFfcCzeHrI3Fuh55vOpo+pLs1BkszUUJMkc75OvC9SnKcnW4H2p+En1HSGx BHdSZZUsEfVtbM7XhlCbxuolKOylHrkwO863xPg0BCRJpmf1tlGpbZhYjm5M0g5/ZdRF GJ3BvPMmB+Op9BQ36pxQdT7kTeWas3BvBS+IQbUFbODgH8f5aeagtNLqDkxCPC//LKFM pLOQ== X-Gm-Message-State: APjAAAU+JvMQspggnjrZvN2XLO1Spd1aEgW7kMCImVEuG8gRXbVDsWQr c5pUx0ADNDiurB6e8kZYx7YEE5XrD0bcWahx3Ards/Gp X-Google-Smtp-Source: APXvYqwY9x78q3ye1uuHXuHzSFCPtCX7Qni8F3mqCic0Tpgh9C2N2gi6D0CHbdt6cnIpFqJSi4jBJ0hd2hw5HuovDPY= X-Received: by 2002:a9d:128c:: with SMTP id g12mr8859481otg.224.1556329692151; Fri, 26 Apr 2019 18:48:12 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20190423173410.8531-1-mgorny@gentoo.org> <20190426163854.37925e6e@gentoo.org> In-Reply-To: From: Raymond Jennings Date: Fri, 26 Apr 2019 18:47:35 -0700 Message-ID: Subject: Re: [gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions To: gentoo-project@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000007443b40587793ee6" X-Archives-Salt: bb35f923-bc7d-43c3-a6d7-7329eb62cf17 X-Archives-Hash: da02943868f79f0337e23ae09037949c --0000000000007443b40587793ee6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What about just at first giving QA the authority to unilaterally revert commits in the event they cause QA violations? Assuming that a QA violation is clear and evident, it seems reasonable to allow it to be reverted immediately without further need for deliberation, since introducing a QA violation could be construed as a regression. If this is done it has the immediate benefit of prompt limitation of damage and goes directly towards what I think is QA's mission. I'm assuming it's implied that an erroneous revert is itself actionable as dereliction of duty by QA. Letting QA handle the immediate task of protecting/maintaining quality standards in the ebuild tree seems the right move. Whether the offending developer should face disciplinary action for violating QA in the first place IMO should be a separate issue. A possible idea is to let QA make a referral to proctors and/or comrel as necessary. For example, for the offending developer's actual QA violation a warning might be issued by proctors. A developer who shows a pattern of negligence, or who deliberately overrides a QA revert, or otherwise aggravates the situation beyond a proctor-level concern could be referred to comrel. The general idea is to let QA take preemptive action as necessary to protect or undo any damage caused by a QA violation, since the tree itself needs protection that may well not benefit from waiting for social procedures involving discipline, and have any disciplinary matters handled as a separate issue possibly with a referral to proctors/comrel. But the gist is having discipline treated as a separate issue that can be handled with social procedures and break off the actual QA task so that the tree's integrity doesn't wait for deliberation. On Fri, Apr 26, 2019 at 6:21 PM Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n < chithanh@gentoo.org> wrote: > Alexis Ballier schrieb: > > > I would add maximum amounts of time everywhere here: For the QA ban > > because this effectively still leaves room for "age of the universe" > > long bans and a slightly shorter one for the comrel response to ensure > > no important ban is missed due to people being on vacations. > > If we agree that QA bans are emergency powers *only* to avert breakage > reaching users, and/or causing unreasonable amounts of work for other > developers to undo, then that would implicitly limit the time of a ban to > whenever the next ComRel/Council meeting can discuss this incident. > > Afterwards it will either be lifted or turned into a ComRel ban. > > > Depending on that maximum, council appeal may not be needed because > > it'd take longer than the ban length anyway. > > I think that ComRel review of the QA emergency decision should be the > default > unless the disciplinary action has expired or was lifted in the meantime. > > But even so, if some QA decision is questionable, bringing it before > Council > is good irrespective of whether it is a past or current matter. > > > Best regards, > Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n > > --0000000000007443b40587793ee6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What about just at first giving QA the authority to unilat= erally revert commits in the event they cause QA violations?

=
Assuming that a QA violation is clear and evident, it seems reasonable= to allow it to be reverted immediately without further need for deliberati= on, since introducing a QA violation could be construed as a regression.

If this is done it has the immediate benefit of prom= pt limitation of damage and goes directly towards what I think is QA's = mission.

I'm assuming it's implied that an= erroneous revert is itself actionable as dereliction of duty by QA.
<= div>
Letting QA handle the immediate task of protecting/maint= aining quality standards in the ebuild tree seems the right move.

Whether the offending developer should face disciplinary ac= tion for violating QA in the first place IMO should be a separate issue.

A possible idea is to let QA make a referral to proc= tors and/or comrel as necessary.=C2=A0 For example, for the offending devel= oper's actual QA violation a warning might be issued by proctors.=C2=A0= A developer who shows a pattern of negligence, or who deliberately overrid= es a QA revert, or otherwise aggravates the situation beyond a proctor-leve= l concern could be referred to comrel.

The general= idea is to let QA take preemptive action as necessary to protect or undo a= ny damage caused by a QA violation, since the tree itself needs protection = that may well not benefit from waiting for social procedures involving disc= ipline, and have any disciplinary matters handled as a separate issue possi= bly with a referral to proctors/comrel.

But the gi= st is having discipline treated as a separate issue that can be handled wit= h social procedures and break off the actual QA task so that the tree's= integrity doesn't wait for deliberation.

On Fri, Apr 26, 2019 at = 6:21 PM Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n <chithanh@gentoo.org> wrote:
Alexis Ballier schrieb:

> I would add maximum amounts of time everywhere here: For the QA ban > because this effectively still leaves room for "age of the univer= se"
> long bans and a slightly shorter one for the comrel response to ensure=
> no important ban is missed due to people being on vacations.

If we agree that QA bans are emergency powers *only* to avert breakage
reaching users, and/or causing unreasonable amounts of work for other
developers to undo, then that would implicitly limit the time of a ban to <= br> whenever the next ComRel/Council meeting can discuss this incident.

Afterwards it will either be lifted or turned into a ComRel ban.

> Depending on that maximum, council appeal may not be needed because > it'd take longer than the ban length anyway.

I think that ComRel review of the QA emergency decision should be the defau= lt
unless the disciplinary action has expired or was lifted in the meantime.
But even so, if some QA decision is questionable, bringing it before Counci= l
is good irrespective of whether it is a past or current matter.


Best regards,
Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n

--0000000000007443b40587793ee6--