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


Attachment: PGP.sig
Description: This is a digitally signed message part

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Reply via email to