On Wed, Nov 15, 2017 at 7:31 AM, Leon Romanovsky <leonro@xxxxxxxxxxxx> wrote: > On Tue, Nov 14, 2017 at 04:38:41PM -0700, Jason Gunthorpe wrote: >> On Tue, Nov 14, 2017 at 10:27:42PM +0000, Parav Pandit wrote: >> >> > > On Wed, Nov 15, 2017 at 12:13 AM, Parav Pandit <parav@xxxxxxxxxxxx> >> > > wrote: >> > > >> From: Or Gerlitz [mailto:gerlitz.or@xxxxxxxxx] >> > > >> > > >> any reason not to point out the commit that introduced the bug? >> > > > No particular reason. I am not sure few years back it was bug or not. In current >> > > code it appear so. >> > > > So I continued without Fixes commit line. >> > > >> > > >> > > The idea is that you do the git blaming and such work to get the >> > > Fixes line, and later, the maintainer of the sub-system and >> > > maintainers of stable kernel use that to decide if/where they want >> > > this to go beyond the -rc kernel you are fixing >> >> > Yes, I understand. But would that be a bug in initial commit, which >> > transport was it handling.. without error code check what could have >> > gone wrong.. I do not have answer for those questions. So I omitted >> > the Fixes line. Wherever I knew for sure in this or other series, I >> > have added. >> >> While the fixes line is nice, the more important question is if any of >> these patches should have a 'Cc: stable@xxxxxxxxxx' ? > > No, this is why I didn't ask to add Fixes line, because stable@ takes > patches in semi-automatic mode by looking after Fixes line. And what's wrong with that? IMHO the right thing to do for fixes is (1) putng the Fixes line (2) cc the author of the offending patch This way you can get them a chance to review the fix and point out to you problems in the patch that may e.g introduce a 2nd problem or a side effect you don't envision. This is what we do on netdev, practically always. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
