Re: Fix quilt merge error in acpi-cpufreq.c

Linus Torvalds
2009-04-16T00:28:01Z

On Thu, 16 Apr 2009, Ingo Molnar wrote:
>
> Is there any other way for us to get the benefits of the impact
> line, without actually adding one?
>
> They are:
>
> - Better split-up patches from contributors.
>
> - Increased maintainer and developer attention on the effects of
> patches.
>
> - Less time we have to spend on patches we get with impact-lines.
> Both hpa and me reported this.
>
> - easy regression post-mortems

None of this has anything to do with "Impact:" per se, and everything to
do with just trying to tach people to talk about their patches better.

By all means, when you see a patch that doesn't describe what it does or
why it does so, ask people to say so.

Ask people "What's the impact of this patch?"

But don't ask them to then say

Impact: cleanup.

Teach them to say

This cleans up the code by doing xyz.

and yes, by all means teach people to write succint and to-the-point
messages.

Teach people to not write a novel, but instead give them rules like:

- the subject line has to descibe the over-all patch.

- Then write a line or two that is about what the patch really does

- if needed, write a longer detailed explanation with actual error
messages that it fixes etc.

Now THAT is somethign that I think we can all get behind. Example of a
good patch log:

kprobes: move EXPORT_SYMBOL_GPL just after function definitions

Clean up positions of EXPORT_SYMBOL_GPL in kernel/kprobes.c according to
checkpatch.pl.

wouldn't you agree? Adding a "Impact: cleanup" wouldn't do anything to it,
except make it not read as good English any more.

I like seeing explanations that read well.

Linus