Re: [Ksummit-discuss] Self nomination - Sasha Levin

["Levin, Alexander" <alexander.levin@verizon.com>]

On Fri, Aug 26, 2016 at 07:56:53AM -0400, Greg KH wrote:
> On Fri, Aug 26, 2016 at 12:42:05PM +0100, James Hogan wrote:
> > On Fri, Aug 26, 2016 at 01:26:35PM +0200, Greg KH wrote:
> > > On Fri, Aug 26, 2016 at 12:46:51AM -0400, Levin, Alexander wrote:
> > > >    - Improving tagging for stable. The "version tag" option is broken
> > > >    and the "Fixes:" tag is always preferable, how do we get people to
> > > >    use that more often? (script it somehow?
> > > >    scripts/find-version-it-fixes ?).
> > > 
> > > Oh a script like that would be nice, but how would that work in reality?
> > 
> > Not all Fixes: tags are suitable for stable though. I've been caught out
> > by patches being applied to stable (4.2 maybe) due to a Fixes tag,
> > without prerequisite patches being applied.
> 
> Yeah, it is true, but it gives me a hint as to where I should stop at,
> or where I should look around at.  If I see a "3.14" mark, and the patch
> doesn't apply at all there, then I'll push back on the developer of the
> patch to see if they can provide a version for that kernel.  If I don't
> have that mark, and it doesn't apply to 3.14, I'll just drop it on the
> floor as "obviously" it doesn't apply there.

Yup, I fully agree that "Fixes:" doesn't guarantee that the commit is stable
material, but in reality neither does the stable@ tag. It's just another
marker for us.

What I was originally talking about is "cc: stable@vger.kernel.org # vX.Y+" vs
"Fixes: hash ("subject"): It's obvious that for and commit that fixes something
there's another commit that broke that thing, but it's also possible that that
commit that broke something fixed something else and made it's way into stable.

Therefore, by using version tags instead of "Fixes:" we have a very good chance
of missing the fact that a certain commit might need to be applied to older
stable trees as well.

-- 

Thanks,
Sasha