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

["H. Peter Anvin" <hpa@zytor.com>]

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.