From: Jonathan Woithe <jwoithe@ph...> - 2009-12-07 00:33:53
> >> I would like to propose the following strategy:
> >> * 2.0-ongoing is only for bug-fixes. No added functionality or
> >> significant rewrites. We'll regularly release 2.0.x versions from this
> >> if required. We try to keep the number of commits to an absolute minimum
> >> on this branch.
> > I would not say minimum but "bugfixing only" as fixing bugs is a good thing in
> > the branch:-)
> Only if the bugfixes don't require massive changes. If that's the case,
> I don't think it's a good idea to do this in an 'ongoing' branch.
Agreed - otherwise we end up having to effectively manage multiple branches
which sucks up time which would be better spent on other things.
> It's better to fix these in the trunk and make a new major release.
> >> * major developments are done in branches from trunk until they have
> >> some releasable maturity. This means e.g. that the RME / saffire pro
> >> developments should really be in a separate branch. Once they are ready
> >> for the (beta) public they can be merged into the trunk. This will avoid
> >> the situation we have in 2.0 where the unfinished functionality had to
> >> be (e.g. DICE) stripped.
> > Yeah, well. Trunk is kind of meant to be broken. Not broken in the sense
> > that incomplete commits happen, but that some minor features might not
> > always work as expected.
> We have to release more often (understatement of the year ;). This means
> that we need more control over the quality of the codebase. So I would
> prefer a repository strategy where we try to ensure that trunk is always
> in a releaseable state (testing).
I don't have a firm opinion about that one way or the other. If this idea
were adopted however, I think we need to be fairly flexible in the
interpretation of it. If a new device driver is being developed (eg: RME)
and that development does not impact on the usability of other drivers then
I see no reason why it couldn't be in trunk - while it may not be usable
itself, it doesn't break trunk and doesn't make other drivers any less
capable. Allowing this kind of activity in trunk would reduce the need for
separate branches to the truly experimental, significant changes. This in
turn will cut down the maintenance overheads. For a project the size of
FFADO I think we need to aim for minimal branching.
Certainly we create branches when needed, but I think a separate branch for
each new "under development" driver is probably going a bit far unless that
development is breaking things for others.