Re: CVS branching -> Git branching model

[Kurt Zeilenga <kurt@OpenLDAP.org>]

On Feb 1, 2012, at 9:26 AM, Hallvard B Furuseth wrote:

> Oh well, sorry about the abandonware stuff.  Getting back to the
> more prosaic subject,

First, whether to use a back-port or a forward-port model has nothing to do with git(1) v. cvs(1).  Both revision control systems support both models. 

Back-port is basically: apply to trunk and back port to releases as needed.  (If a bug is only in X and older releases, then apply to X branch and back port from there.)  You never forward port in the back-port model.

Forward-port is any model which requires forward porting.  There's variants here, some of which also require back-porting.

> I do think it'd be better to do more coding
> in a branch off RE24 than off master - except stuff intended for
> RE25 in the first place.

The back-port model is generally better in my opinion.  It effectively eliminates the risk of regression that is high in any forward port model.

Your suggestion will lead to regressions and hence, IMO, bad.  It's also messy, time consuming, and error prone from a release engineering stand-point.

It is important for the release engineer to control what goes into release branches.  If you code off the release branch, then the release engineer has to be involved early and frequently.  It is far easier to do "batched" release engineering but forward porting models are incompatible with "batched" release engineering.

As far as branching is concerned, my only recommendation is to avoid 'feature' specific development branches in the main repo.  Instead, personal (but shared) repos can be used.  If appropriate, we can even host these on openldap.org.   But even these don't really cause any release engineering issue and hence shouldn't be a big concern.  It might be nice to archive these (and the old non-release CVS branches) once they are no longer in use, just to reduce the noise.  Personally, I prefer not to archive old release branches (as I find them useful long after they are closed).

But, in general, I advocate leaving well enough alone... especially if it not helping our release engineers (or worse, will cause release engineering pain).

-- Kurt


> Or code which starts intended for RE24
> but ends up waiting for RE25, which is maybe what I remember as
> abandonware:-(
> 
> Once everything intended for RE24 is in the RE24 branch, we can
> merge that branch (or its descendant maintenance branch) to
> master but not the other way around, and the code can hopefully
> be merged instead of cherry-picked into RE24.
> 
> Also holding the door open for 'hotfix' branches should help, and
> killing old CVS branches, like mentioned in the original mail.
> 
> -- 
> Hallvard
>