Messages in this thread | | | Date | Wed, 15 Apr 2009 11:47:49 -0700 | From | "H. Peter Anvin" <> | 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.
| |