Messages in this thread | | | Date | Wed, 15 Apr 2009 17:23:42 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Fix quilt merge error in acpi-cpufreq.c |
| |
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
| |