lkml.org 
[lkml]   [2009]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fix quilt merge error in acpi-cpufreq.c

* David Miller <davem@davemloft.net> wrote:

> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed, 15 Apr 2009 12:43:02 -0700 (PDT)
>
> > And if it _is_ obvious, then the mechanical "Impact:" thing is pointless.
> >
> > In other words - in neither case does it actually help anything at all.
> > It's only distracting noise.
>
> FWIW I find the Impact: blurbs highly annoying too. Just freakin'
> say what the damn patch does in the commit message.

Just curious: have you tried to use them over a couple of days, just
to check whether your first read-only impression is correct, that
they are just annoying blurbs with no other effects? (you might have
- I dont know.)

> If a person can't be bothered to skim the commit message text,
> this Impact: tag only gives them a false sense of understanding
> what the change does.

So do you consider it wrong to summarize impact? Does this argument
extend to other summaries as well, such as the title itself? Or is
your argument that there should be only a single kind of summary in
a commit - the title itself?

Also, would it be wrong for people to be able to skim commit logs
only for 'interesting looking' commits, by using impact tags? Should
they be 'punished' by us obfuscating away summaries intentionally?

Also, do you think hpa was not telling the truth when he said that
it is much faster for him to review patches that have an impact
line? Do you think i am not telling the truth for reporting the same
experience? Isnt speed and effiency of review something we should be
happy to improve?

Ingo


\
 
 \ /
  Last update: 2009-04-16 00:51    [W:0.109 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site