[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers

James Bottomley James.Bottomley at HansenPartnership.com
Tue Jun 19 13:09:49 UTC 2012

On Tue, 2012-06-19 at 08:59 -0400, Steven Rostedt wrote:
> On Mon, 2012-06-18 at 13:53 -0700, H. Peter Anvin wrote:
> > On 06/18/2012 01:50 PM, Jiri Kosina wrote:
> > > 
> > > Well, sometimes it's not immediately obvious from the changelog what kind 
> > > of bug is actually being fixed (and yes, I know that for some of the 
> > > security fixes this is on purpose :-) ).
> > > 
> > > So, speaking with my SLES kernel maintainer hat on, having some 
> > > 'categorization' of the bug that is being fixed by a particular -stable 
> > > patch, would be extremely helpful.
> > > 
> > 
> > This seems to be going down the rathole that we tried to address with
> > the "Impact:" notes in -tip.  It didn't work :(
> I think the problem with this was that we required that tag for all
> commits. We started getting redundancy, especially when the subject
> basically stated the impact as well.
> Then we also had:
>    Impact: clean up
> For things like code clean ups and such. It did become a bit of a
> burden, and I thought it made the change log a bit ugly. I still cringe
> when I'm going through old commits and see them.
> But I do believe that the idea was valid, just the way we implemented it
> was flawed. Adding a tag or something to what is fixed may be useful.
> And only add it for things that actually fix something. Or perhaps
> require it for any commit that has a stable tag on it. If you Cc,
> stable, you should have something like:
>   Cc: stable at vger.kernel.org
>   Fixes: Crash on board Foo

How does this help at all?  If the change log is properly written, you
get the impact statement out of it anyway (plus more nuance and far
better insight into whether it should be backported).  People who write
bad changelogs will just do 

Fixes: a bug 


Impact: set the bit 2 instead of 3

anyway; and people who write good changelogs tend to have already put
the impact in the one line summary and then fret about what to write as
an Impact: line.

The bottom line is that adding more tags and process to changelogs
doesn't solve the fundamental problem which is that a lot of people
can't write good changelogs in the first place.


More information about the Ksummit-2012-discuss mailing list