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

[Linus Torvalds]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/