[Chandler-dev] How we develop post Preview : SVN topology

[Philippe Bossut]

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/%3c46BA27C5.10507@osafoundation.org%3e) 
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