On Dec 7, 2005, at 2:18 PM, Phillip J. Eby wrote:
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.
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.
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.
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.
--- Bear Build and Release Engineer Open Source Applications Foundation (OSAF) [EMAIL PROTECTED] http://www.osafoundation.org [EMAIL PROTECTED] http://code-bear.com PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
PGP.sig
Description: This is a digitally signed message part
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
