public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Raymond Jennings <shentino@gmail.com>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions
Date: Fri, 26 Apr 2019 18:47:35 -0700	[thread overview]
Message-ID: <CAGDaZ_ohWcr9KcUFNHAos5rJTeJ7NnPyAetC+Tto5TNanA99Og@mail.gmail.com> (raw)
In-Reply-To: <a0a4290d-beea-1a1a-f0ca-547960aa7d39@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]

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í-Thanh Christopher Nguyễn <
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í-Thanh Christopher Nguyễn
>
>

[-- Attachment #2: Type: text/html, Size: 3637 bytes --]

      reply	other threads:[~2019-04-27  1:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 17:34 [gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions Michał Górny
2019-04-26 14:38 ` Alexis Ballier
2019-04-27  1:21   ` Chí-Thanh Christopher Nguyễn
2019-04-27  1:47     ` Raymond Jennings [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGDaZ_ohWcr9KcUFNHAos5rJTeJ7NnPyAetC+Tto5TNanA99Og@mail.gmail.com \
    --to=shentino@gmail.com \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox