[dpdk-dev] RFC: DPDK Long Term Support
thomas.monjalon at 6wind.com
Mon Jun 6 16:23:22 CEST 2016
2016-06-06 22:14, Yuanhan Liu:
> On Mon, Jun 06, 2016 at 03:31:09PM +0200, Thomas Monjalon wrote:
> > 2016-06-06 19:49, Yuanhan Liu:
> > > On Fri, Jun 03, 2016 at 06:05:15PM +0200, Thomas Monjalon wrote:
> > > > 2016-06-03 15:07, Mcnamara, John:
> > > > > Developers submitting fixes to the mainline should also CC the maintainer so
> > > > > that they can evaluate the patch. A <stable at dpdk.org> email address could be
> > > > > provided for this so that it can be included as a CC in the commit messages
> > > > > and documented in the Code Contribution Guidelines.
> > Why put a CC tag in the commit? For automatic processing?
> > Maybe it is too early to run before walking ;)
> It's a tip/trick used a lot in kernel community. Assume you have made
> a patchset, that just one of them fixes a bug that you hope this patch
> could also be cc'ed to the original author that introduces the bug.
> You could achieve that by adding him to the cc list from cli. However,
> in such way, all patches are cc'ed to him. The alternative is to add
> a line "Cc: some.one <some at one.com>" in the commit log so that he will
> get that patch only.
> If you look at a small micro optimization patchset I sent out last
> month , you will find that I used this trick for the 1st patch,
> as it touches the core part of virtio-net vring operation, that I
> hope I can get some comments from the virtio guru/maintainer, Michael.
> Therefore, he is cc'ed. However, for the 2 other patches in the same
> set, it's basically DPDK vhost-user stuff, so that I didn't cc him
> to not bother him.
> This rule, of course, also applies to the stable branch (for bug
> fixing patches in a set). It doesn't matter which way you take if
> it's just a patch set of one bug fixing patch though.
> : http://dpdk.org/ml/archives/dev/2016-May/038246.html
More information about the dev