[Dev] Rotating build sheriff duties?

[Andi Vajda]

On Wed, 7 Dec 2005, Phillip J. Eby wrote:

> 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!

+1

> Then our organization is in need of improvement, because we are doing one or 
> more of the following:
>
> 1. failing to build a consensus,

+1, this sheriff thing is a very good example

> 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)

+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?

Just as with the tinderboxes, if the tools are flaky, the process is going to 
be broken.

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

+1

>> 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!

+1

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

+1

Andi..