On 8/10/07, Nicolas Pennequin <[EMAIL PROTECTED]> wrote: > IMO this is exactly what using branches is meant to avoid. Declaring a > feature > freeze on the trunk is one of the reasons the last attempt at a 3.0 release > failed. Most devs simply weren't interested in doing *only* bugfixing work.
I don't think this would be different if we had a branch. Devs not interested in bugfixing will continue to work on new features, and only a small group will do the fixes. But it would need additional work to port fixes in a release branch to trunk and I don't see much people interested in doing that work. Also, if trunk is freezed, I see a (tiny) possibility even those people with new features on hold to help fixing bugs -- just to end the freeze earlier so they can commit their stuff. So not freezing trunk might getting the bugs fixed even slower ... And of course anyone can use local branches for ongoing development. That's a bit like git treats it: if you branch you'll do it locally. If a public branch is wanted for developing new features during a freeze some git mirror could be used. Aren't you a fan of git? ;-) > If we were to freeze the trunk past a certain date instead of branching, > someone who had a new feature to add but missed the freeze date would be > frustrated both of having missed the release deadline and of having to > maintain a patch he can't commit because of the freeze. Well, that's life. We need to communicate such a freeze to avoid such frustration but we can't satisfy everyone -- as we can't among users. Just think of the discussion about the changed voice file format on the users-ml. (And IIRC freezing trunk wasn't a real problem the last time we did.) - Dominik
