On Dec 7, 2005, at 2:50 PM, Andi Vajda wrote:
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.
With SVN (and even CVS) you just cannot "override" access without having access to the server - that would mean that each person who wanted to commit would need to connect to the server, flip the config file to enable their acount, commit, flip it back and then log out. Sounds worse than just telling people to be aware (which they should be anyway IMO.)
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.
Notifying people by email works in a perfectly sanitized world where everyone is responding to their emails in a timely manner, but it just doesn't work that way in real life. heck, even now I sometimes have to email people two or three times, send them pings on IRC and once had to phone someone to get them to notice that their change had broken the build.
I just don't get why this is such a hard or tedious task - don't devs already have a "best practices" list of things to do:
- check code status to make sure you have latest build - verify your code works with latest tests - verify you are only checking in code that you want to check inand so on - why not just add "check tinderbox in X minutes" to make sure your change hasn't broken the different OS related builds?
--- 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
