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. > For instance, it's not uncommon in some > parts of the codebase to discover and fix bugs as part of a feature > branch (because it's doing new things that weren't previously > exercised), tag the bug fix as a backport, and then generate tickets > later (assuming we're behaving). Cheers > -Greg > -- > 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 > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
