From: Dominik Riebeling <dominik.riebeling_at_gmail.com>
Date: Fri, 10 Aug 2007 16:02:22 +0200

On 8/10/07, Nicolas Pennequin <nicolas.pennequin_at_free.fr> 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
Received on 2007-08-10