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