[Dev] Builds, Release and Tinderbox

[Mike Taylor]

Now that I'm doing this full time, I figured I would re-iterate what 
steps people should follow as related to builds.  Most of these items 
are fairly loose except when we get into either a code-freeze or come 
within a couple days of a release.  Please give me any feedback if any 
of these seem extreme or un-warranted.

   - please test your change on at least one other OS
   - *always* run at least unit tests before a check-in, smoke tests are 
preferred
       see 
http://wiki.osafoundation.org/bin/view/Chandler/TestingChandler for 
more information
   - after a check-in, wait for the quick builds to fully cycle
   - if the change is to internal/ or external/ please wait for one of 
the full builds to do a full cycle

Also, be on IRC or be checking your email - if a build goes red I will 
be sending an email if I don't see any activity.

If a build does go red what I normally do is wait at least two full 
cycles before sending an email about the issue.  If by the third cycle 
I don't see any activity in CVS I will be backing out the change.  For 
the branch, the change will be backed out immediately unless you 
contact me otherwise.

On the day of a release, any tinderbox failure will cause an immediate 
reversal and I would like anyone doing commits to be readily available.

thanks,

---
Bear
http://code-bear.com

Open Source Applications Foundation (OSAF)
http://www.osafoundation.org

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20050322/85d33715/PGP.bin