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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090416000841.GA18185@elte.hu>
Date:	Thu, 16 Apr 2009 02:08:41 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, hpa@...or.com,
	tglx@...utronix.de, rusty@...tcorp.com.au,
	linux-kernel@...r.kernel.org, davej@...hat.com
Subject: Re: Fix quilt merge error in acpi-cpufreq.c

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

> On Thu, 16 Apr 2009, Ingo Molnar wrote:
> >
> > As i said it in the mail, i actually used the impact line of 
> > commit 6b44003e5ca66 ("work_on_cpu(): rewrite it to create a 
> > kernel thread on demand") later on, when a regression was caused 
> > by that commit.
> 
> Duh. You keep on repeating that idiotic argument.
> 
> The "Impact:" part had nothing what-so-ever to do with what you 
> argue for.
> 
> I'm not arguing against good commit messages. I'm arguing against 
> the "Impact:" part. It's pointless.
> 
> ALL of the commit message is (hopefully) about important things. 
> If you want to narrow it down to one single line, that's just 
> WRONG.

Ok, i see your argument.

Is there any other way for us to get the benefits of the impact 
line, without actually adding one?

They are:

 - Better split-up patches from contributors.

 - Increased maintainer and developer attention on the effects of
   patches.

 - Less time we have to spend on patches we get with impact-lines.
   Both hpa and me reported this.

 - easy regression post-mortems

What i dont understand is how you can dismiss these positive points 
so easily and only concentrate on the negative points - these 
effects are mostly visible to those creating impact lines - not to 
you. You cannot really have seen any of these effects without having 
done impact lines for a few days.

(
  Okay, you are perhaps an exception, you _do_ write fantastic
  commit logs that generally need no 'stinkin impact line.

  There's exceptions though, even with your commits. I wish you had 
  added one to ea34f43a for example, which you committed today.

  It is not clear from that commit log at all what the practical
  relevance of your fix is.

  I suspect it fixes Ali Gholami Rudi's problem of his CPU hitting
  50^C till the fan turns on.

  I'd probably have added the following impact line (although i'd
  have first asked Ali whether this is the precise impact the fix
  had on him - it's not 100% clear from the discussion):

    Impact: fix cpufreq misbehavior causing high CPU temperature

  Does this information matter? I think it does. Does it matter 
  _more_ than the rest of the commit log? I think, to most Linux
  users, it does. That's one of the reasons why we are experimenting 
  with formalized this kind of information. It's important 
  information and it should not be forgotten from commit logs.

  As a developer, while writing up a commit log it is _so_ easy to
  get lost in the details of the 'how' and 'why' - and not emit
  basic information: why do people care? What were the bad
  _practical_ effects of the bug that are fixed here?

  It is basic human nature to get lost in that - even for the best.
)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/