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

[Russell Bryant]

Luigi Rizzo wrote:
> === 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.

That was exactly the reason that the policy has been the way it is.  The only
commits that go to more than one place are supposed to be true bug fixes.  We
wanted to make sure that they got into releases ASAP, and also wanted to help
ensure that bug fixes actually made it into releases and didn't get lost.
Before, all commits went to trunk, and backports to the release (1.0, at the
time) were done later, and there was no good way to make sure none of the fixes
got lost.

> 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.

I guess the way I have looked at it is that if a bug fix is significant enough
that it deserves additional testing attention, then it should go into a
developer branch while being tested.  Once the fix is deemed ready, it would be
merged into the appropriate main branches (1.4 and trunk, in the case of a bug fix).

Well, with the plan I had in mind, features that need testing would go into
developer branches.  After the adequate testing, they would be merged back into
trunk.  The 1.6.X releases would be branched directly off of trunk, and then
given more testing on the new things that have been merged into trunk since the
last 1.6.X release.

I guess we both agree that there should be some sort of buffer before changes
make it into a release.  I have just seen the developer branch area the place
for that, and that stuff shouldn't get into trunk (or 1.4) until it's "ready".

> === 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).

When it comes to supporting multiple 1.6.X branches, I was only suggesting the
possibility of supporting multiple branches for security issues, which are rare
in comparison to how often things are changed for bug fixes.  However, I can
still see how it could be a nightmare ...

I also agree that having to support 1.2, 1.4, and 1.6 would be difficult.
However, we get a lot of pressure from our community for this kind of thing.
People coming from the traditional telephony world are used to not having to
update their phones systems for many years.

I think maintaining 2 releases is a pretty good balance - one deprecated release
maintained for security issues, and the current release series.  I would like to
eventually have only 1.4 and 1.6, but I think we need some more time.  Getting
people to even give 1.4 a chance over 1.2 has been a very difficult process.
It's going to take some time before we can completely deprecate 1.2, maintain
1.4 with security fixes only, and then only actively work on 1.6.  If we do it
too soon, there is going to be a _HUGE_ backlash from the user community.  We're
going to have to give them time to buy into it.

> === 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.

Very good point.  I can see how in a more actively developed release series, it
becomes more important to maintain the ability to upgrade and downgrade even a
specific module.

I'm very interested in learning some more about the tricks that you have used in
the past to extend APIs while preserving compatibility.  This is not something I
have really dealt with much before.

A strict API/ABI freeze is not something I really had in mind for 1.6.  If that
was the case, then we would really need a dedicated 1.6 branch instead of just
using trunk as the staging area for 1.6.X releases.  I had figured that once a
new API and related changes had received adequate testing in its developer
branch, that it could be then merged into trunk (and thus, 1.6 releases).  But,
that would break some level of ABI compatability, at least.

I'm going to have to continue to put some thought into this one.

> === 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.

Sounds good.  Let's take the next month or so to consider both what to do in
regards to an API/ABI freeze for the 1.6.X series, as well as what API changes
we would like to get done before such a freeze were to go in effect.

Thank you very much for the feedback,

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.