[Dev] Rotating build sheriff duties?

[Bryan Stearns]

+1 to everything Phillip said so far

Phillip J. Eby wrote:

> At 12:19 PM 12/7/2005 -0800, Heikki Toivonen wrote:
>
>> - when restarting from scratch there is no information to determine what
>> changed in this cycle (actually, everything changed). maybe we don't
>> care about automating this edge case
>
>
> I would simply use the last successful test run's revision number as a 
> basis for determining "what changed" since the last success.
>
>
>> - there's nobody to make sure that people actually act on the email, or
>> that they even are there to read the email in the first place (I would
>> expect the sheriff to call if there is no response to IRC or email ping)
>
>
> We could manage that through escalation - first failure email is to 
> developers, second failure is to sheriff, third to Dev list.  Or 
> something based on time the failure has been outstanding without a 
> response.
>
> Again, what bothers me about this is what it says about the 
> organization.  Are we *so* down on each other that our assumption is 
> that people don't want to do the right thing?  If so, that's a *much* 
> bigger issue than our build mechanisms or policies!
>
>
>> We already have a guideline, but some people are not following
>> it - sometimes by accident, sometimes systematically because they
>> disagree with the guideline.
>
>
> Then our organization is in need of improvement, because we are doing 
> one or more of the following:
>
> 1. failing to build a consensus,
> 2. failing to enforce an established consensus, or
> 3. making a big deal out of something that's not actually important to 
> the organization (which is really just a variant of #1)
>
>
>> Even though I am generally process-oriented, I am not so sure I would
>> want some script prevent me from committing because of some format issue
>> in the commit log - what if the script is simply wrong for this
>> particular instance?
>
>
> Then you edit your message and try again; no harm done unless your SVN 
> client doesn't let you do that.
>
>
>> * Although maybe theoretically possible, it seems like a far stretch to
>> say the script can check if the checkin type was allowed (for example,
>> only blocking bugs + comments + docstrings on 0.6 branch where blocking
>> bugs need a bug number an a reviewer).
>
>
> When you say "comments + docstrings", what do you mean?  The other 
> facets, like having a reviewer for the exact patch and having a 
> blocking bug certainly seem like objective criteria to me, that can be 
> checked using available data.
>
>
>> * I don't see any 100% reliable way to check that the bug number was
>> actually correct.
>
>
> If a review is required, then there should be a patch attached to the 
> bug whose contents match the commit.
>
>
>> * Did the checkin comment actually explain anything, or was it more or
>> less just some filler to get past the format checker?
>
>
> One difference is that it's harder to rationalize omitting information 
> if the fields are all right there.  But again, see my comments about 
> organizational issues, which will not be resolved by automation any 
> more than they will by rotating sheriff duty.
>
>
>> Btw, note that we already get a failure message on IRC. In my experience
>> people ignore them. Maybe they wouldn't if the message specifically
>> mentioned their nick.
>
>
> Exactly.  90+% of tinderbox failures have absolutely nothing to do 
> with me, so even if I set up audible notification for those IRC 
> messages, I would quickly learn to tune them out.
>
>
>> Also, Tinderbox very prominently states when the tree is closed. You are
>> supposed to check Tbox before checking in. And bear also sends out
>> email. Yet we still get a few checkins when the tree is closed every now
>> and then.
>
>
> Which is an indication that the *process* is broken, not that the 
> developers need to be whacked harder!
>
> Frankly, if the process you're describing were a program whose design 
> I were reviewing, it would get a failing grade for inherent 
> concurrency bugs.  It only seems not to be broken if you're on the 
> build/release management side, because you always know what the status 
> is or is going to be.  On the developer side, it can sometimes take me 
> a minute or two to write a good commit message, during which time the 
> tinderbox status could change.  This fact alone guarantees that there 
> will sometimes be checkins when there shouldn't be.
>
> The only sane way to manage checkin traffic control is for Subversion 
> to reject checkins.  Anything else *will* produce "race condition" 
> failures, which we then get to beat up the developers for, even if 
> it's not their fault.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev