On Dec 1, 2008, at 12:10 PM, Rick Altherr wrote:
There is never a good time to make a branch. That's why you choose tools that allow easy merging between branches and the trunk. I wouldn't say that the 1.0 branch was cut too early. It isn't entirely clear that all of the changes committed to trunk should be pulled back into the branch. Once a branch is cut, each commit to trunk should be evaluated for the branch. The evaluation should consider risk vs reward and only merge in changes that have high reward for the risk (i.e. if the risk is low and the reward is low, it's ok. If the risk is medium and the reward is high, it's ok. If the risk is high but the reward is medium, don't take it). That way things that improve the quality without introducing instability are merged into the branch. That methodology advocates cutting a stable branch relatively early to avoid destabilizing changes from making it into the release.-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."-- Unsigned _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Thinking about this more, the real problem is that no one has been designated as the release coordinator for 1.0. One person should be responsible for watching commits to trunk and evaluating them for inclusion into the branch. If any changes are necessary for the branch, this person should be responsible for working with the original patch creator to make the necessary modifications. This person should also be the one to merge changes into the branch. Without such a person, the stability of the branch is at risk.
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
