Jared Rhine wrote: > Are any specific methodologies planned to be changed? Faster/better > branching support could perhaps enable some new approaches. One that > occurred in passing is that a tag or branch could be used during > milestone builds to avoid locking the tree. Also, tinderboxen could > build against tagged releases, similarly avoiding locking the tree > when a tinderbox goes red. Longer term (with more server resources), > developers could work in branches with developer-specific tinderboxes, > and code could be reviewed during whenever code is promoted to the > trunk.
No changes in processes are planned. We are actually using tags and branches, and locked tree periods are very short, generally less than two hours for checkpoint and milestone builds. We build all checkpoints, milestones and releases from tags. We lock the tree because if we need to do some changes it is painful to move tags (at least in CVS). We branch for releases, but we wait until the there is only a small number of changes anticipated on the branch. The reason for this is that it is painful for developers to maintain two trees and check to two places at once, and also for QA to test branch and trunk. We gradually wind down on checkins after feature freeze, so there will be some period of time near a release when new feature development slows down. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
