On Mon, Apr 13, 2015 at 10:28 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > > Hi Greg, > > On 13/04/2015 19:04, Gregory Farnum wrote: >> On Mon, Apr 13, 2015 at 9:48 AM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: >>> A while ago this came up in #ceph-devel and I wanted to bring it to a >>> wider audience. >>> >>> Should we stop the convention of adding the "backport: " tags in Git? >>> >>> Loic brought up the point that this data is essentially immutable after >>> we merge it, and it's better to point at a Redmine tracker where we can >>> alter the "backport" field. >>> >>> This makes it easier to adjust the "backport" data after the code's been >>> merged to master. It also makes it easier for whoever is corralling the >>> backport efforts, because the person only have one place to look >>> (Redmine) instead of two (Redmine + git commit logs). >>> >>> For what it's worth I agree with Loic on this. >>> >>> Any objections? >> >> Why don't we just treat the backport commit tag as an expected value, >> and any corresponding redmine data as the canonical one? > > That's what we currently do, I think. > >> I find the >> backport tags to be useful when reviewing commits and I think the >> authorial intention matters. > > A git-notes could be added for that purpose instead. Huh, I'm not previously familiar with that mechanism. Is there any particular reason you didn't use that for tracking backport states to begin with? It looks like it's sort of designed for this purpose. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
