On Apr 15, 2008, at 5:55 AM, Graham Leggett wrote:
The solution is simple: leave it on trunk, remove it from the v1.3.0 branch until the issues are resolved, so that the folks wanting to see v1.3.0 released are not prevented from making that happen. I don't think anybody would have objected to the suggestion to do so.
Actually, trunk is supposed to be what we are all working on together (in its currently working form). In a CTR model, it is fairly important that objections to the current trunk be addressed immediately, either in the form of a correction or a revert, since otherwise a whole bunch of people sit around waiting for the change to occur before continuing. If an objection cannot be resolved immediately, then the accepted mechanism is to revert on trunk and continue work on a separate feature branch or sandbox (easily done by copying the trunk and re-applying the revert to a branch of trunk in reverse mode). That gives anyone working on the problem the ability to resolve the objections on their own schedule (or abandon them without harming group progress). Note that this imposes extra work on the person wanting the change, as opposed to imposing extra work on everyone else to work around the incomplete trunk. I am kind of annoyed that a branch was done for 1.3.x before any release of 1.3.0. My opinion is that encourages folks to think of trunk as a dumping ground, which is fundamentally bad because trunk is the basis for collaboration. However, since Bill is the likely RM, I assume he has some plan in mind that I haven't considered. ....Roy
