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 <[email protected]> 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:[email protected]] On Behalf Of Hefty, > Sean > Sent: Monday, November 27, 2017 4:41 PM > To: [email protected] > 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 <[email protected]> > > or > > TAG: stable > Signed-off-by: Oscar <[email protected]> > > 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 > [email protected] > http://lists.openfabrics.org/mailman/listinfo/ofiwg > _______________________________________________ > ofiwg mailing list > [email protected] > http://lists.openfabrics.org/mailman/listinfo/ofiwg -- Jeff Squyres [email protected] _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
