[Development] Proposal: Allow contributors to +1 sanity review.

Oswald Buddenhagen oswald.buddenhagen at digia.com
Tue Aug 13 20:18:28 CEST 2013

On Tue, Aug 13, 2013 at 10:26:42AM -0700, Alan Alpert wrote:
> On Tue, Aug 13, 2013 at 2:22 AM, Oswald Buddenhagen
> <oswald.buddenhagen at digia.com> wrote:
> > On Mon, Aug 12, 2013 at 02:32:34PM -0700, Alan Alpert wrote:
> >> So all that happens is that there will be cases where the bot gives a
> >> false positive and contributors need to ping again for sanity review -
> >> a needless step.
> >>
> > actually, it's a very useful step. people are trying to override the bot
> > all the time because they don't get the intentions behind a particular
> > report
> Or they get that the intention of a heuristic it to guess and realize
> that it's not always right?
we hope they do. the likelyhood that they do is way higher when
approvers make the decision.

> > (or because they enjoy outsmarting the system just for the sake
> > of it, like you apparently do)
> We *define* the system. The fact that I have to work around it in
> order to do my job properly shows that the system is defective and
> needs to be rectified.
or it means that you are not doing your job right, and are trying to
find loopholes to outsmart the system.

> A more effective change which I recommend would be to have the bot not
> give -1 on the heuristics which are known to give false positives more
> frequently.
at this point there are no heuristics which are known to give false
positives often. when you often get a -1 for something you consider ok
by defintion, then it's time you rethink your position and to look for

> > having an approver (i.e., somebody who
> > is expected to be familiar with the coding style, commit policy, etc.)
> > take the decision to override the bot is very much part of the plan.
> The point is that the approver has already decided to approve.
nonsense. they approved the code and the text. they didn't necessarily
think of the subtleties of the process and the formalities of what makes
a good git commit, or are among the whitespace-blind themselves. to
verify sanity reports many people need to change into an entirely
different mindset. so it is a *good* thing that it needs to be done

i for one *always* do sanity overrides in a separate review, simply so
it's clear that the comment i write (you know that you are required to
add a plausible justification, right?) relates to the sanity review.

More information about the Development mailing list