lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 15 Apr 2009 17:23:42 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Andrew Morton <akpm@...ux-foundation.org>, hpa@...or.com,
	tglx@...utronix.de, rusty@...tcorp.com.au,
	linux-kernel@...r.kernel.org, davej@...hat.com
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ