[Dev] Rotating build sheriff duties?

[John Anderson]

+1

Phillip J. Eby wrote:

> At 02:20 PM 12/1/2005 -0800, Heikki Toivonen wrote:
>
>> Phillip J. Eby wrote:
>> > At 01:57 PM 12/1/2005 -0800, Heikki Toivonen wrote:
>> >
>> >> Thoughts? Anyone absolutely opposed to participating? If so, why? 
>> Other
>> >> ideas?
>> >
>> > Couldn't we automate quite a few of these things?  ISTM that a sparse
>> > rotation like 1 day/month means nobody has any real chance of getting
>> > good at doing it; it'll always be a sort of, "Um, what was I 
>> supposed to
>> > do again?" thing.  At least, I'm pretty sure that's what I'd be asking
>> > each time it was my turn.  :)
>>
>> We would obviously need a page describing what to do and how.
>>
>> What things do you think could be automated?
>
>
> Almost everything on your original list, actually.
>
>
>>  How?
>
>
> Pre- and post-commit scripts, and some modifications to the build and 
> test processes to track the SVN revision being built, to associate 
> error logs with specific tests.
>
>
>>  How much work would
>> that be? Who would do the work?
>
>
> I doubt the actual implementation will be complex; the hardest part is 
> probably standardizing on a commit message template or format.   By 
> which I mean the hard part is getting everybody to agree on it, not 
> its actual implementation.  :)
>
> As for who, I'd certainly be willing to do some or all of it.  I think 
> it wastes a lot of time and goodwill to have people being grilled or 
> criticized after the fact for checkin policies that could be 
> automatically enforced.  For example, if a particular tree is closed, 
> we simply shouldn't accept commits to it.  This is far more humane to 
> developers than trying to make them keep track of when they should or 
> shouldn't be doing what.  We're programmers - we're used to having the 
> machine tell us we did something wrong, and then dealing with it.
>
> 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."  :)
>
> (Actually, it's even crazier than that.  Apart from Tinderbox 
> monitoring, It sounds to me like we're talking about having a rotating 
> duty to keep an eye on everybody else, instead of having people be 
> responsible for doing their own good work *every day*.  That sounds to 
> me like an organizational failure, because either some of this stuff 
> really isn't that important, or the organization is failing to 
> communicate its importance, or is unwilling to actually make the 
> investments in automation and education (including coaching and/or 
> consequences) to get the issues resolved.  (I leave out the 
> possibility of "bad eggs" being an issue, because the continued 
> presence of bad eggs would itself be an organizational failure; i.e. 
> failure to coach/discipline/remove.))
>
>
>>  Don't get me wrong, though, I would be
>> delighted to have more stuff automated but I am somewhat skeptical of
>> automating the duties I outlined.
>
>
> I think that the intent of all of the things you mentioned can be met 
> through greater automation.  I expect I'll be getting involved in the 
> build process and our tools during the 0.7 timeframe, so I'll 
> definitely be looking for opportunities to address those issues.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev