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

Ingo Molnar
2009-04-16T00:46:37Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 16 Apr 2009, Ingo Molnar wrote:
> >
> > So do you consider it wrong to summarize impact?
>
> No.
>
> NOBODY is arguing against talking about what the thing does.
>
> We're arguing against the string "Impact:", which is nonsensical.
>
> > Does this argument extend to other summaries as well, such as
> > the title itself?
>
> Umm. The summary line that doesn't have such a made-up nonsensical
> prefix?
>
> Ingo, you're missing the _point_.
>
> Summaries and good description of patches are GOOD.
>
> The "Impact:" string is just noise.
>
> Talk about how it was a cleanup all you want, and by all means
> talk about what the intention of it was. Nobody argues against
> that. What we argue against is ugly language.
>
> Describe the changes in real sentences.

So would a:

The impact of this change: it is a pure cleanup.

Formalization be acceptable? We tried to make it short and fit into
a single line - but we can certainly make it longer.

Btw., we have a _lot_ of 'summary' tags in commit logs already, all
over the place. Added by you, me and everyone who commits changes
into Linux.

They might not be nearly as intrusive and repulsive to you as the
now infamous "Impact: " line, but they are all over the place and
boy are they ugly to any sane person on this planet - you just got
used to them already.

Starting with the title:

x86: rename .i assembler includes to .h
x86: add instrumentation menu

That 'x86:' prefix is a summary and a prefix string. We dont say
what the English, Finnish, Swedish, Hungarian or German teacher
taught us to be proper language:

The x86 architecture code: rename .i assembler includes to .h

Den x86 arkitekturen koden: ge nytt namn .i assembler omfattar till .h

Because we found that too long, and because after a few months of
getting used to everyone parses "x86: " prefixes automatically.

Just like we learned to parse "fuse: " prefixes a few years ago and
do it sub-consciously now - despite it being arguably bad language
(what is there to fuse??).

In fact, the .i and .h abbreviations are summarized information
meaningless to anyone outside of this field. Often we use language
variants specific to one Linux subsystem. Worklet? Syslet? skb? vma?
Signed-off-by? Cc:? RIP? ALSA?

We sometimes paste formal descriptions into changelogs, when it
serves us well:

// <smpl>
@disable is_null@
identifier f;
expression E;
identifier fld;
statement S;
@@

+ if (E == NULL) S
f(...,E->fld,...);
- if (E == NULL) S

And abbreviations, summaries and ways of expressions evolve. They
evolve when people start using them in new ways. Does it happen
often? Yes, it does. Can it be bogus and harmful? Yes, it can be and
most often it _is_ bogus, so scrutinizing it is correct.

So the real question is not artificial abbreviations, but the
_level_, _style_, _efficiency_ and _placement_ of such summarizing,
and whether you accept an "Impact: " prefix as a meaningful and
worthwile way to summarize a given category of information. You
clearly dont, and i dont for a minute dispute that you find it
genuinely ugly, and i'm not ignoring your view about that.

You just dont seem to understand why i find it useful. You also seem
to try to deprive us the basic right of creating new, field-specific
language variants we find useful in our everyday work. And that
sucks.

q.e.d.

Oops, i should have said, quod erat demonstrandum.

Ingo