[dpdk-dev] [PATCH] devtools: check stable tag in fixes

Thomas Monjalon thomas.monjalon at 6wind.com
Tue Jan 17 19:42:33 CET 2017

2017-01-17 18:15, Ferruh Yigit:
> On 1/17/2017 2:54 PM, Thomas Monjalon wrote:
> > The tag "Cc: stable at dpdk.org" must be set when the commit must be
> > backported to a stable branch.
> > 
> > It must be located just below the "Fixes:" tag (without blank line)
> > and followed by a blank line, separated from SoB and review tags below.
> I am OK to keep it if it will help stable tree maintenance, but I still
> not clear about why we need this.
> If a patch is a fix, it should already have "Fixes:" line, so this can
> be used to parse git history.

That's a question for Yuanhan. My comments below:

Some fixes are not candidate for the stable branch because the bug was
not in the previous release. These fixes are filtered out by the script
Some fixes are not so important and we can decide they do not fit in
the stable branch. Who make this decision? Relying on this Cc tag would
mean the committers decide which patch to backport.

> If patch is a feature, as far as I know still can go to stable tree, but
> for this case stable tree maintainer decides this, and author putting
> "Cc: stable at dpdk.org" tag not so useful. Author can put this tag just
> for recommendation, but if so why we are saving this into git history?

No feature should be backported.

> Initially this was to be sure fixes CC'ed to stable mail list, now
> meaning is changing I guess. For the case author already cc'ed the
> stable tree but not put Cc: tag into git commit, should committer add
> this explicitly or ask from author a new version of the patch?

Yuanhan was suggesting that the committer can do it if an author forget.

> Last thing, if this tag will remain in the commit log, is this only for
> stable tree, or any "Cc: <mail_address>" can stay in the history?

I do not see the benefit of keeping other Cc in the history.
It is just a convenience for authors when using git-send-email.

More information about the dev mailing list