[asterisk-dev] merge policies, supported branches, API/ABI freeze (was Re: Asterisk 1.6 Release Management Proposal)

[Luigi Rizzo]

Long reply below, but please read it - i have some concerns on the
following items:
+ merge policies - bottom up or top down ?
+ number of supported versions - 1.2, 1.4, multiple 1.6.x, trunk. Too many ?
+ importance of API/ABI freeze in the "stable" branch
+ timing of the 1.6/trunk fork
All of the above comes from my experience in FreeBSD over the past 10
years, where we experienced a number of these issues and had
both successful strategies and sometimes mistakes from which we
tried to learn.

Details follow:

On Wed, Oct 17, 2007 at 02:22:52PM -0500, Russell Bryant wrote:
> Michiel van Baak wrote:
> > Not really important for me because I dont have commit
> > access but I wonder how the merging from 1.4 to 1.6 to trunk
> > will go. I know how it works now (commit to 1.4 and block in
> > trunk otherwise it will go to trunk 'automagically').
> > 
> > Will there be branches with automerge from a 1.6.X
> > subrelease?
> 
> Actually, we don't use automerge for trunk.  The only place automerge is used is
> in the developer branch area (team/ directory).
> 
> Regarding merge order, the only change is that there may be one additional
> commit required, if the patch fixes a regression introduced in the 1.6.X branch
> that is in testing.  So, where now a change goes through:
> 
> 1.4 ---> trunk
> 
> it may now go:
> 
>     |---> 1.6.X
> 1.4 |---> trunk

=== First item: merging policy ===
I have always been extremely unhappy with this commit policy, because
in principle it means that you are going to test fixes in what is
the "stable" branch, and in practice (encouraged by svnmerge, which
is not "automerge" but close enough) it's even worse as it encourages
instant commits on both branches with no real testing except on the
committer's machine - just look at the commit logs to see how often
you see at least two replicas of a commit (in 1.4 and trunk) within
minutes.

Now, one could try to defend that policy if it is only limited to
true bugfixes, on the grounds that i) you want to fix the stable branch
ASAP, and ii) you don't want lazy committers forget about the old
releases.

But now that it is finally recognised that true new features are
also being slowly pushed into the "stable" branch, it really makes
no sense to adopt this policy.

New code should be tested in trunk, and pushed down after appropriate
testing. The amount of delay may change depending on the type of
fix/feature, but instant commits should be the exception not the
norm, probably confined to security issues only.

=== Second item: number of supported branches ===
On a related topic, as it appeared elsewhere in this thread: I think
it is unsustainable to expect to support multiple 1.6.x branches
(in addition to 1.2, 1.4 and trunk).  This will only fragment the
user base among the various versions, and create a mainteinance
nightmare. At one point in FreeBSD we had 2.x, 3.x and 4.x all under
active support, and it was very difficult to handle (even more so
with 4.x, 5.x and 6.x which had very different internals).

=== Third item: API/ABI freeze ===
If anything, one should enforce a slightly different policy on the
-stable branch: don't worry too much about features, but be extremely
strict on not changing APIs (possibly even at the binary level),
so that people will always have the choice of upgrade/downgrade individual
modules if they are not happy with them, or if there is a regression.

Note that the API/ABI freeze is a critical one that requires some thinking,
and a careful study on what is now in trunk to see whether it is appropriate
or it might require some cleanup. I am especially thinking of the astobj2
stuff, which has been recently introduced. Note that a frozen API/ABI
doesn't mean that it is not an extensible one - if there are areas where
we think that something may need to change during the lifetime of 1.6,
we can always put version numbers on the structs or play some tricks to
enable extensions while preserving backward/forward compatibility.
This is something that worked very well in FreeBSD.

=== Fourth item: timing of 1.6/trunk fork ===
Considering the above, i think that before forking 1.6 it is really
necessary to have a bit of discussion on the API/ABI that should remain
stable across 1.6 (and this should happen for real, not be something
that is only true on paper). I don't believe that this will take less
than a month or so.

cheers
luigi