Message-ID: <1386449757.2195.30.camel@jtkirshe-mobl>
Date:	Sat, 07 Dec 2013 12:55:57 -0800
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Cc:	davem@...emloft.net,
	Anjali Singhai Jain <anjali.singhai@...el.com>,
	netdev@...r.kernel.org, gospo@...hat.com, sassmann@...hat.com,
	Jesse Brandeburg <jesse.brandeburg@...el.com>
Subject: Re: [net-next 09/14] i40e: Enable all PCTYPEs except FCOE for RSS.

On Sun, 2013-12-08 at 00:20 +0300, Sergei Shtylyov wrote:
> On 12/07/2013 10:36 PM, Jeff Kirsher wrote:
> 
> >>>>> From: Anjali Singhai Jain <anjali.singhai@...el.com>
> 
> >>>>> RSS can steer packets based on recognition of all
> >>>>> sorts of different headers.  Enable some more of them.
> 
> >>>>> Change-Id: I2264dedae66fb0bceca6fb6e772e050e3ca8efc8
> 
> >>>>       This line has no place in the upstream patches, and I'm seeing it
> >>>> in several patches of this series.
> 
> >>> This is an internal hash id, so that we can track upstream changes back
> >>> to internal git tree changes.  I did verify that this was acceptable and
> >>> is being used in the kernel in upstream patches before pushing this
> >>> information.
> 
> >>      First time I hear about that. Its use is constantly denied in
> >> linux-usb at least.  Maybe netdev has its own rules regarding this though...
> 
>     Greg KH seems to be persistent in being negative towards its use. I also 
> react semi-automatically whenever I see it, asking to remove it. Anyway, it's 
> really DaveM's issue whether to allow it.
>     The main issue with it is that it doesn't contain any useful information 
> to an ordinary person browsing kernel commits, it's exactly for the internal 
> use only.

Well, I would disagree on the point that it would be for internal use
only.  While it is a internal git hash, it helps us support the Linux
community by helping us track the internal history of the patch for
support and changes.  So customers could give us either the Linux kernel
hash (in which turn we would find the internal hash id information from
the patch description) or could give us the I<hash>.  So you are right,
we would be the ones using the information to help support you and
everyone else.

Personally, the more information you can put in a patch description
(without writing a novel), the better.  While I was not originally a fan
of the "Change-Id:", the positives out-weighed any negative argument.

> 
> > Take a look at `git log --format=oneline --grep="Change-Id"`
> > You will see there are instances in arch as well as in wireless and in
> > other areas as well.
> 
>     I saw only 3 screens of commits (expected to see more) without much system.
> 
> > So we are not doing something new or the only ones using this tag.
> 
>     I didn't say that (in fact, quite the contrary).

Sorry, I inferred that from the response you originally sent.

> 
> > Google appears to be using it as well based the following information:
> > https://gerrit-documentation.storage.googleapis.com/Documentation/2.7/user-changeid.html
> 
>     Why should we care about what Google does?

I was just giving you background on where this tag appeared to originate
from.  I was not trying to say "Ooo Google does this, so we should
too..."

> 
> > Places using gerrit:
> > http://code.google.com/p/gerrit/wiki/ShowCases
> > This is the largest example of a "Change-Id:" tag that I know of.
> 
>     I didn't see the Linux kernel in this list, only Android.

Neither did I, but I did find the use of it in the Linux kernel before
we decided to adopt the practice.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists