Re: [Ksummit-discuss] [CORE TOPIC] stable workflow

[James Bottomley <James.Bottomley@HansenPartnership.com>]

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

On Thu, 2016-08-04 at 16:44 +0100, Mark Brown wrote:
> On Thu, Aug 04, 2016 at 09:33:55AM -0400, Steven Rostedt wrote:
> > Greg KH <greg@kroah.com> wrote:
> 
> > > No, again, that would put more burden on the maintainer and 
> > > developer than I want to "enforce".  I don't even want to do that 
> > > extra work for the trees I maintain, I just couldn't scale that
> > > way.
> 
> > Note, this isn't just good practice for sending patches to stable, 
> > it's general good practice maintaining code. It gives a nice
> > history of
> > a
> > change. If you look at the change log of code that one might see
> > that
> > looks "interesting" it may be very educational to see that it was
> > done
> > as a fix for something else. And a new developer may understand why
> > code was added in the first place.
> 
> If it's a choice between me taking a bugfix for mainline and me 
> getting someone to give me a commit ID for exactly which commit 
> introduced some change I'm probably not going to do the latter, 
> especially when a lot of these things are more of the "we now 
> understand the hardware better" variety.
> 
> > I don't buy this as burden on a maintainer. This should be part of 
> > the maintenance procedure, regardless of sending to stable or not. 
> > Yes it does take extra time, but I don't think that time is wasted.
> 
> I'm really happy we've got people engaging upstream.  I'm happy if
> people fill in the extra information but really I'm way more 
> interested in a clear changelog than in getting a Fixes tag, or in 
> checking that the tags people are adding are accurate.

Why not look at this in a different way: any bug fix that's correcting
a prior commit is actually a regression.  The reason we treat
regressions differently (and actually have someone to track them) is
that they're the ones users hate: it means that something that was
previously working (and thus relied on) suddenly doesn't work any more.
 Note that not every bug fix with a fixes tag is a technical
regression: if the fixes tag is actually the commit that first
introduced the feature it's not a regression because the non-buggy
behaviour was never visible to the end user.  However, the people who
track regressions are capable of sorting this out.

What I'm pointing out is that Fixes: has uses that go way beyond
stable.  That's why I do think it's good practice for the kernel.  It's
something we should already be doing that can assist the stable
process, not something that's just been invented for the purpose.

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]