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

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 4 Aug 2016 16:44:44 +0100
Mark Brown <broonie@kernel.org> wrote:


> 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.

Who said anything about a choice between one or the other?

> 
> > 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.

Having a clear change log is orthogonal to having a Fixes tag. Actually,
in my experience, change logs with Fixes tags tend to have clearer
explanations in the change log than those without. Because to get that
Fixes tag, one did some research to why the bug happened in the first
place.

> 
> 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.

For some exotic driver it is probably not as important for clear change
logs and fixes tags, as there's not many users and who knows, maybe the
hardware wont exist in the future when we would want to look into the
history of the code.

I mostly work in the core kernel, and any part of the kernel that has a
much larger area of use would greatly benefit from having clear change
logs as well as Fixes tags that point to regressions, or even if the
bug was there all along. It helps out in many areas besides just
stable. As James mentions, it helps for regression tracking which is
something that people have been wanting to return.

I found a bug in an old version of the kernel that I was using and when
I looked upstream, there was a fixes tag. Not only did I easily find
the proper fix, but it helped me see that the broken code was indeed in
the kernel I was playing with. That's something similar to having
stable releases, but it helps out any other users that are using older
kernels.

-- Steve