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? I find the backport tags to be useful when reviewing commits and I think the authorial intention matters. 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). -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
