[asterisk-dev] Proposed change to branch revision blocking policy

[Kevin P. Fleming]

As it stands right now, when someone commits a change to Asterisk trunk,
it get either merged or blocked in the release branches (1.6.0 and
1.6.1). However, this is resulting in a large number of what appear to
be pointless commits to the 1.6.0 branch, which then have to be pruned
out of the ChangeLog when we make the next 1.6.0.y regression fix release.

Once a 1.6.x branch has reached the release candidate phase (not when
the branch is made), that branch is no longer a candidate for any
changes *except* fixes for regressions in that branch. As such, nobody
is ever going to run 'svnmerge avail' on that branch to see what is
available to be merged, because every fix that would possibly be merged
into the branch during that process is supposed to be already there!

Ideally, the same situation would be true during the time that the 1.6.x
branch exists but has not yet been released, as every bugfix commit to
trunk should be merged to that branch immediately by the developer who
commits it to trunk, but since that doesn't always happen we still have
to run an 'svnmerge avail' before making release candidates to ensure
nothing got missed.

So, I'm proposing that once a 1.6.x branch has reached the release
candidate phase, we stop using svnmerge to block revisions there, as it
results in useless 'noise' commits. When there are multiple 1.6.x
branches that have had releases, this problem would only multiply.

Comments?

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)