[Dev] Rotating build sheriff duties?

[Andi Vajda]

On Wed, 7 Dec 2005, Mike Taylor wrote:

> The only reason I don't turn off commits is that for every release cycle it's 
> only *certain* devs who shouldn't commit - many times a commit is needed by 
> me or qa or the product team to tweak version #'s, docs or other non-code 
> related items.

Have a way to let these people override a closed tree. The point of the 
automated closed tree is to prevent people who are not *aware* that the tree 
is closed from committing. If they know the tree is closed and still need to 
commit - for example, to fix the bug that caused the tree to be closed in the 
first place - they should then go into this proposed override mode.

>> Meanwhile, we could save the should's and shaming for things that matter 
>> more than raw procedure, especially since it's clear that they aren't 
>> working very well for this.  To be honest, the idea that we should do 
>> *more* of it rather than less, strikes me as "The kids are being rowdy, 
>> let's try hitting them harder."  :)
>
> What people *need* to do that they are not is simply watch the Tinderbox page 
> - when you commit and the tree starts to show failures all devs who commited 
> code should be looking at the reason why.

No, no and again no. If the tinderboxes are smart enough to know who the last 
committers were and are smart enough to know that the build or tests are 
failing they are obviously smart enough to send mail or otherwise ping on irc 
the allegedly guilty parties. If they do it in mail, the tinderboxes should 
also send the complete stack trace of the failure, something that can be a 
pain to extract via the browser interface.

> It really is that simple - the rotating sheriff duty would not be needed at 
> all if each dev would monitor the build status page when they commit.

It is really that simple - the rotating sheriff duty would not be needed at 
all if tinder boxes were nagging the allegedly guilty parties via email or 
irc.

Andi..