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]

Message-ID: <alpine.LFD.2.00.0904151406380.4042@localhost.localdomain>
Date:	Wed, 15 Apr 2009 14:15:45 -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 Wed, 15 Apr 2009, Ingo Molnar wrote:
> 
> Impact line exposes wrong patch structure: cleanup should never be 
> mixed with fix.
>
> impact line somewhat atypical but correct - the patch is a cleanup 
> but might affect user-space.
>
> Impact line is correct.
> 
> Impact line is not duplicative of subject line.
>
> Impact line is incorrect (describes action not effect).
> 
> Impact line is correct and appropriate.

Bah. 

In _no_ case did the Impact: line actually say anything worth saying, and 
it was there just for self-gratification. 

> - only 0.85% of the commits you were involved with in this cycle had 
>   an impact line.
> 
> - out of 5 cases, 4 had correct impact lines, despite _you_ 
>   admittedly not liking them and not caring about them.

Just about NOBODY cares about "correct".

I care about this "mental masturbation" part, where somebody decided to 
start marking commits with some inane logic that makes no sense.

Instead of havign that IDIOTIC "Impact:" marker, why not just write good 
commit messages?

That's the issue. Those things have no meaning. 

Quite frankly, your argument of using "grep" on those things for 
management is total crap. It would make sense if they were meaningful and 
ubiquotous, but neither of those are actually true.

And your arguments are really so _incredibly_ dishonest that I don't see 
how you can't not see that yourself. Let's quote one:

> |     lockdep: warn about lockdep disabling after kernel taint, fix
> |    
> |     Impact: build fix for Sparc and s390
> |    
> |     Stephen Rothwell reported that the Sparc build broke:
> 
> I added that 'build fix' impact line for two reasons:
> 
> Firstly, because the subject line was inherited from the buggy 
> commit and the new subject line got a ", fix" postfix. (This 
> convention seems rather useful at times in shortlogs, see below.)

THIS counts as an argument for adding an "Impact:" line?

Come on - sure, it's worth mentioning that the patch is a build fix, but
that should obviously have been there regardless of any "Impact:" line. 
So your whole argument is based on the fact that you added a (good) piece 
of information, but you ignore the fact that that good piece of 
information had NOTHING WHAT-SO-EVER to do with the "Impact" line. It 
should have been there regardless.

		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/