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
