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

[Niel Lambrechts <niel.lambrechts@gmail.com>]

On 04/16/2009 06:00 AM, Theodore Tso 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.  I was
> came across a recent set of commits sent to you where it was
> pathetically obvious that Impact: doesn't really help.  
> 
> The patch submitter in question was a non-English speaker.  I've
> blacked out the submitter's name, because I'm not trying to call out
> that particular person, but rather the assumption that Impact: is
> always helpful.  Here's a very clear case where it is not.
> 
> I do feel your pain; there are one or two ext4 contributors where I
> always have to rewrite their commit logs and comments, and often I end
> up staring at the code trying to figure out what the !@#@? they meant.
> I used to try to coach them to make better messages, but I've since
> given up and just resigned myself to the fact that it's up to me
> rewrite the commit logs (and often, the comments in the code, too...)
> 
> If we are going to use the Impact: header, there should only be a few
> standardized values that it can have, i.e., "clean up", "fix oops",
> "fix lock ordering", "fix performance problem", etc.  Otherwise people
> will just put garbage in the Impact field --- what the heck does
> "Impact: it is not ready yet.  remove it" mean?  
> 
> Or "Impact: fix smp_affinity when moving irq_desc"?  
> 
> Or worse yet, "Impact: so use dev_to_node"?!?

Sorry if I'm speaking out of turn, would it not be more meaningful to
have "Tags:" or a "Keywords:" instead of a subjective impact assessment?

As for"Impact" - does the author at time of creation really know all the
possible problem permutations a specific piece of code might cause or
apply to?

Tags could however be helpful to someone that is not the developer or
maintainer.

As a real life example from an issue I just had, I would be inclined to
google for "brightness cannot be controlled by keyboard" rather than
gleaning anything from "i915: Register ACPI video even when not
modesetting" - even though that probably is a really clear commit
message in context of being the developer / maintainer.

It is not quite the same as "Impact", since someone else with XYZ laptop
might have some other issue as a result of the same commit.

The developer already has at least an entire paragraph to describe the
technicalities for his direct audience, but what about making the
problem context easier to understand (searchable) for the interested
outsiders? :)

cheers
Niel