[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
reasons.

> > 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
separately.

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