Hi,
We had a discussion yesterday during the Chandler Desktop meeting
(http://chandlerproject.org/Journal/AppsMeeting20070904) on how we
should handle the SVN tree structure. Note that we had a similar
conversation at the beginning of August
(http://lists.osafoundation.org/archives/chandler-dev/200708.mbox/[EMAIL PROTECTED])
but that one thread was focused on branching for 0.7.1 under short term.
At the time, devs voted not to branch at all and, basically, punt the
"how we manage new development" discussion for later. Well, with Preview
getting out anytime now, this "later" task is tickling to "now" (to take
some Chandler triage terminology).
I'll try to summarize the talk we had yesterday here under in an as
condensed as possible way:
Goals/Needs:
g1- Allow a new patched/bug fixed version of the officially released
version to be built and shipped anytime
g2- Allow new developments to start as soon as possible
g3- Allow new developers to svn sync, build and start experimenting with
the code without much hassle
g4- Keep everybody focused on the right thing
g5- Allow a much frequent release cycle of major releases (e.g. every 2
months)
Possible strategies:
1. 2 main branches: one for "open" dev work going toward the next major
release and one for "restricted" commits to fix the official release
s1.a: Evergreen trunk: use the trunk for 0.7.x (restricted commit) and
open a dev branch. When the dev branch is stable, merge it to the trunk
(or call it the trunk) and repeat.
s1.b: Open dev trunk: use the trunk for open dev toward the next major
release, open a branch for 0.7.x work. Note: wxWidgets for instance is
using such a strategy.
s2. Multiple dev branches: maintain the trunk evergreen, devs develop on
their own branch and merge onto the trunk once their feature/change pass
tests and scrutiny by the community. Note: used on really big FLOSS
projects (Linux) and by commercial projects (considered as best practice
under Perforce for instance).
Plan of record (current work strategy): s1.b with delay:
- trunk limited to 0.7.x changes (actually, we're still waiting for
0.7.0 to be officially declared so don't commit anything on behalf of
0.7.1 yet) till bug load goes down to 25 (quarter of what it is today)
- branch then and open trunk to "dev" commit (implement s1.b)
Personal opinion: my gut is to go with s1.b because the topology is easy
to grasp and the implementation cost is minimum. It worked with other
projects (wxWidgets) and, considering how small our community of devs
still is, it's the most productive solution. Also I've seen s2 used in
some places (no no, no name :) ) and the overall productivity can really
crawl to frustrating levels during the "integration" phase of any single
sub project.
One problem with s1.b is that I can imagine that within a couple of
months (or less), some devs will have to merge back lots of their
changes in 2 branches and, pretty soon, double develop because the trunk
will have diverged too much (problem mentioned by Andi during the
discussion and confirmed by Robin as to what happens on wx). If we
release often though this shouldn't be too much of a problem.
The really big problem I see with s1.b is that it may make g5 (make
frequent releases) difficult to reach: the trunk might be so messed up
that releasing a new major release will take months of stabilization
work. That's the biggest argument in favor of s2: since major
developments are maintained separately and merged at once only when
stable and reviewed on their own branch, we can (in theory) release a
major update with "whatever made it" anytime with minimal stabilization
work to do. I think that if we have lots of contributors, that would be
the best strategy. But between "keep momentum" and "act as a 1,000
contributors project", I'm choosing "keep momentum".
The mitigating factor with s1.b though to achieve g5 is that only *few*
devs have commit privileges and that new contributors need to go through
patch proposal/approval. Also, s1.b doesn't prohibit some major "scary"
developments to happen on dev branches so that we don't mess up the
trunk too much (we did that several times in this past year with EIM,
recurrence changes and repo changes for instance). I think we'll have to
ask devs to branch for some feature development (e.g. contacts) so that
we can take a decision to merge or not merge a big feature in a new
release with confidence and not find ourselves stuck in a long
stabilization cycle. For everything else, s1.b allows us to to make
serious incremental changes (bug fixes, dev clean up, limited
refactoring, small features) on the trunk with minimal process hurdle
and limited risks (I'm assuming we stick with "generalized post commit
code review" as is used on Cosmo).
Hope to hear devs opinions on that subject soon.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
