[ofiwg] managing stable branches

[Jeff Squyres (jsquyres)]

What is the goal of this tag?

Putting a "TOKEN:VERSION" string in the commit message implies that the developer knows at commit creation time which release branch(es) the commit needs to be cherry picked to.  Is this always the case?

I see 2 use cases:

1. The developer knows at commit creation time that the commit needs to be cherry picked to a release branch.  The developer therefore puts "TOKEN:VERSION" in the commit message.  At some point later, the developer scours the git logs looking for their commits with "TOKEN:VERSION" so that they can cherry pick them to the release branch.

2. The developer *doesn't* know at commit creation time that it needs to be cherry picked to a release branch.  In this case, the developer puts "TOKEN:master" in the commit message.  Later, the developer won't be able to scour git logs looking for what needs to be cherry picked.

Here's the problems I see with this:

1. This scheme presumes that the developer knows that a commit needs to be ported to a release branch at commit creation time.  However, we don't have a well-defined scheme for releases from release branches -- they happen on an ad hoc basis, such as when someone has a critical bug fix to put out.  But then others pile on and put in non-critical bug fixes.  And it's exactly those non-critical bug fixes are somewhat hard to find by scouring git logs.  But those commits will be marked with "TOKEN:master", so this scheme won't help find those commits.

2. The majority of commits only need to go to master.  Adding "TOKEN:master" strings to all of those commits seems like it does not optimize for the common case.

I think that if a developer knows that a commit needs to go to a release branch, he/she should put a label on the master PR containing the commit(s) that need to be cherry picked that will remind the developer to make a release branch PR when that master PR is merged.

Just my $0.02...


> On Nov 27, 2017, at 8:09 PM, Paulson, Erik R <erik.r.paulson at intel.com> wrote:
> 
> I like the idea, but I don't support using the word "TAG" since that word is already associated with both git tags and tag-matching. I propose that we use "Backport-To:" or "Cherrypick-To:".
> 
> 
> Best,
> 
> Erik Paulson
> 
> -----Original Message-----
> From: ofiwg [mailto:ofiwg-bounces at lists.openfabrics.org] On Behalf Of Hefty, Sean
> Sent: Monday, November 27, 2017 4:41 PM
> To: ofiwg at lists.openfabrics.org
> Subject: [ofiwg] managing stable branches
> 
> There are currently 2 stable branches actively being updated - 1.4.x and 1.5.x.  Up until this point, stable branches have resulted in limited additional work -- at least to anyone other than me :).
> 
> To assist with the process, I'd propose including a tag the signed-off-by area to indicate if a patch should be cherry-picked.  This is similar to the linux-kernel method.  For example:
> 
> TAG: v1.5.x
> Signed-off-by: Big Bird <bbird at sesame.street>
> 
> or
> 
> TAG: stable
> Signed-off-by: Oscar <scram at sesame.street>
> 
> If we use this, we would need to select the 'TAG' (or just use 'TAG'), as well as listing what values are possible (specific branches or general stable).
> 
> - Sean
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg


-- 
Jeff Squyres
jsquyres at cisco.com