On 04/13/2015 07:53 PM, Gregory Farnum wrote: > 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. I agree. git-notes seem like the way to go for this -- also, mind blown at finding about git-notes, looks amazing! -Joao -- 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
