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

James Bottomley James.Bottomley at HansenPartnership.com
Wed Jun 20 08:42:34 UTC 2012

On Wed, 2012-06-20 at 10:31 +0200, Jiri Kosina wrote:
> On Tue, 19 Jun 2012, James Bottomley wrote:
> > > 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 
> > 
> > or
> > 
> > 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.
> My whole point when initiating this discussion was how easy we'd like to 
> make it for distros to cherry-pick patches from -stable in cases when they 
> are in development phases in which they can't afford taking the whole 
> -stable release.
> Going through all the changelogs, and analyzing whether it's appropriate 
> as a "super-crucial-must-have" bugfix or not is very time consuming and 
> not really easy, especially if done by someone who is not in daily contact 
> with the code in question.
> So I agree that "Impact:" or "Fixes:" lines are mostly useless in Linus' 
> (any most of the other) trees, but I'd personally very appreciate those in 
> -stable from the distribution (i.e. customer of -stable) point of view.

But Jiri, whether a bug is super critical or not depends on *your*
distro viewpoint, not that of the person writing the change log.  As you
already said, what constitutes critical changes as the distro release
goes forwards.  How can you really expect us to make that decision for
you?  The best we can really do is describe exactly and concisely what
the problem and the fix is in the change log and let you decide if it
meets your criteria.


More information about the Ksummit-2012-discuss mailing list