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

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:	Thu, 16 Apr 2009 09:44:06 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Theodore Tso <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, hpa@...or.com,
	tglx@...utronix.de, rusty@...tcorp.com.au,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	davej@...hat.com
Subject: Re: Fix quilt merge error in acpi-cpufreq.c

* Theodore Tso <tytso@....edu> wrote:

> On Thu, Apr 16, 2009 at 03:46:42AM +0200, Ingo Molnar wrote:
> > 
> > For similar reasons people have memos, stick-it's and other formal, 
> > automated, reflex-alike daily routine measures to make sure they 
> > dont forget to do something they all too easily forget otherwise.
> ...
> > This kind of formal measure _forces_ the extraction of this very 
> > specific type of summary on all sides of the contribution chain - 
> > and it drastically reduced the number of commits i regretted in 
> > hindsight.
> 
> The question is whether Impact: _works_ in its current form. [...]

For us, it clearly works in most cases. Does it work in _every_ 
case? No. No maintenance measure ever works in every case.

> [...]  I was came across a recent set of commits sent to you where 
> it was pathetically obvious that Impact: doesn't really help.

The thing is - none of the examples you quoted below are commits in 
any of our trees! They are email submissions to lkml, not applied 
yet anywhere. And yes, from the impact line alone it becomes clear 
that the commit log needs serious editing.

And yes, in fact it became _easier_ to me to process patches from 
that particular patch submitter you blacked out, since he started 
using impact-lines a few months ago. These bad impact lines you 
quoted are of course not usable directly in a commit log - but they 
are canaries. Plus the ones where i for example get "Impact: 
cleanup" patches from him are certainly useful.

So even this worst-case example you could possibly can come up with 
is in reality actually a success story to us!

Impact tags allow frequent contributors to pre-tag changes with a 
"this I expected to be an easy one" easily recognizable attribute. 
It is very helpful, _especially_ where there's a language barrier.

Here's an easy challenge: try inserting perfect impact lines for a 
few days into all your commits, really! :-) [ You can erase them 
after you've created them, and you dont have to admit it ever that 
you did this experiment ;-) ]

I noticed that even the best commits win a new dimension of quality 
and awareness as far as the maintainer is concerned. It also helps 
us keep our eyes on the ball all the time: constantly assessing the 
true utility and true risk of our patches.

It's truly useful, and unless you try it seriously and come back to 
us with a "I tried it, all my impact lines were perfect but it didnt 
give me any plus so i stopped doing it" i dont think you can ever 
know what you missed out on.

	Ingo
--
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/