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

[Jiri Kosina]

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.

-- 
Jiri Kosina
SUSE Labs