+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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
