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

[Michiel van Baak]

On 07:26, Tue 07 Oct 08, Kevin P. Fleming wrote:
> 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?

+1

-- 

Michiel van Baak
michiel at vanbaak.eu
http://michiel.vanbaak.eu
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x71C946BD

"Why is it drug addicts and computer aficionados are both called users?"