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

[Steven Rostedt]

On Tue, 2012-06-19 at 14:09 +0100, James Bottomley wrote:

> 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

The idea is to force people to summarize what they fixed. But this needs
to be done with or without an impact tag.

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

I agree that is an issue. Maybe we need to push maintainers to push back
on change logs. Not to pull if a change log is not up to stuff. Or have
Linus or Greg start being more vocal when they see crappy change logs.

If something is tagged with 'stable' it had better have a good change
log. Maybe make that a requirement to go into stable. But then again,
with git, once it is in Linus's tree, it can't change.

It really comes down to reviewing patches. We do not have enough
reviewers, or at least we do not have a good process for reviewing. I
myself have been trying to send out RFC patch sets before I start
posting pull requests. Because, when I post a pull request for Ingo, if
Ingo pulls it in and then someone notices a bug, that bug will stay in
the repo, because Ingo follows the 'do not rebase' rule. The bug fix
will go on top. That's if it is noticed then.

This is another argument to have a linux-devel repo that people can have
development code go into, and become a single repository for work. Lots
of people may push their 'here's what I'm doing' to their own repos, but
few people will see it. If we have a single "development" repo, it will
get a lot more viewers and vet out bugs before they even hit linux-next.
This may not solve the bad change logs, but we can encourage people to
review changes that go into this repo, and complain about change logs,
to get developers to write better ones.

-- Steve