[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers
jkosina at suse.cz
Wed Jun 20 08:31:04 UTC 2012
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
> 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
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.
More information about the Ksummit-2012-discuss