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.

One thing I've told driver authors before is that the big thing I'm
looking at for drivers for hardware which has limited distribution is
the impact it has on the subsystem and maintainability - to a great
degree if nobody can tell if the driver works there's a limited extent
to which I'm going to care about things.  That doesn't mean I'm not
reviewing at all but there's always a point where I just can't tell.