Rockbox mail archiveSubject: Re: Rockbox development model
Re: Rockbox development model
From: Nicolas Pennequin <nicolas.pennequin_at_free.fr>
Date: Fri, 10 Aug 2007 14:54:23 +0200
On Friday 10 August 2007 08:45:43 pondlife wrote:
> > 4-6. Everyone is encouraged to fix bugs in the rel-3.0 branch.
> Maybe this should be in the trunk - i.e. bug fix week or freeze. That
> saves us having to fix said bugs in both trunk and 3.0.
IMO this is exactly what using branches is meant to avoid. Declaring a
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.
Using a branch to avoid feature freeze gives a choice between adding new
features in the trunk (which shouldn't be encouraged) and fixing bugs in both
the release branch and the trunk.
Of course you could say that fixing in both branches is a duplication of
effort, but at this point it should be quite trivial to do, as the branches
shouldn't be too far apart.
> > 7. ...After this (or possibly during 4-6), new features should get into
> > trunk...
> If you do 4-6 as per your plan, then new features must be allowed into
> trunk immediately (i.e. no freeze).
> If you do 4-6 as I suggest above, then we only allow new features at 7.
As I said above, adding new features to trunk between branching and release
shouldn't be forbidden, but simply not encouraged. What is most likely to
happen anyway is that people will try to get their new features in before the
branching because they'll want them to be in the release. Then it's expected
that they should at least help debug their features.
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.
Received on 2007-08-10