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: <49E62BD5.6090508@zytor.com>
Date:	Wed, 15 Apr 2009 11:47:49 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: Fix quilt merge error in acpi-cpufreq.c

Linus Torvalds wrote:
> 
> The thing is, I've seen totally bogus "Impact:" statements.
> 
> It just makes things look more official, without actually guaranteeing 
> that it's any more correct. For example, I've seen impact statements to 
> the effect of "cleanup", when (a) it wasn't and (b) it did other things 
> too.
> 
> At that point, it's just distraction and wrong.
> 

It's more than that: it's a red flag; an indication that the committer
didn't pay attention.  We hopefully notice and reject such patches (or
perhaps more frequently, fix their impact lines).  An error is indeed
problematic, but it can (and *should*) be recognized after the fact as
well and can be used to improve maintenance practices.

> And in fact, "cleanup" seems to be the most common one. Along with other 
> totally useless ones like "fix build" or just "Fix" .

"cleanup" is indeed the most common, as it is intended to signify a
trivial but nonzero code change.  Whether or not it's *correct* is
another matter.  "build fix" is valid and proper use: it tells that it
fixes a compilation error, which succinctly communicates both the
priority of the fix and how it needs to be validated.

> shows several "cleanuips" that are anything but. Those "cleanups" fix 
> build errors or actually change code. The "Impact:" statement is actively 
> misleading, adds absolutely _nothing_, and detracts from the real issue 
> and the real message.

One of the problems we do have is the lack of standardization; the
reason for that is that we started this out as an experiment, and
weren't really ready to crack down too hard on the exact usage.  This
of course means, too, that the meaning is slightly different for
different people, and although we can fix that for patches we commit, we
can't do that for other trees.

In short, I think we've gotten to the point that we need a spec in the
Documentation/ directory for this to continue to be useful.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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