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: <20090415200724.GA12202@elte.hu>
Date:	Wed, 15 Apr 2009 22:07:24 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: Fix quilt merge error in acpi-cpufreq.c

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

> On Wed, 15 Apr 2009, H. Peter Anvin wrote:
> > 
> > "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.
> 
> Why would that be "proper use"?
> 
> Dammit, if the "build fix" is not obvious from the rest of the 
> commit message, there's something wrong.
> 
> 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.

I often skip "Impact: build fix" - when it's obvious from the 
subject line or the first sentence of the commit - or if it can be 
made obvious by changing the subject line or by changing the first 
sentence of the commit.

I add it occasionally, when some other, higher priority principle 
makes the changing of the subject line undesired.

For example, yesterday i did this commit:

| commit 27b19565fe4ca5b0e9d2ae98ce4b81ca728bf445
| Author: Ingo Molnar <mingo@...e.hu>
| Date:   Tue Apr 14 11:03:12 2009 +0200
|
|     lockdep: warn about lockdep disabling after kernel taint, fix
|    
|     Impact: build fix for Sparc and s390
|    
|     Stephen Rothwell reported that the Sparc build broke:

I added that 'build fix' impact line for two reasons:

Firstly, because the subject line was inherited from the buggy 
commit and the new subject line got a ", fix" postfix. (This 
convention seems rather useful at times in shortlogs, see below.)

Secondly, i also added the impact line because i wanted to specify 
the architectures affected: Sparc and s390 - this fact was not 
obvious from the bug report context which i wanted to preserve to 
credit the bug reporter prominently (Stephen found the build error 
on Sparc only).

Another option would have been to use this primary subject line 
instead:

   fix build error on Sparc and s390

But IMHO that's a worse subject line. It's more important to keep 
the flow of the original change intact. The subject lines cluster up 
better in shortlogs or in git logs:

 $ gll include/linux/debug_locks.h 
 27b1956: lockdep: warn about lockdep disabling after kernel taint, fix
 9eeba61: lockdep: warn about lockdep disabling after kernel taint

The connection between the two commits is plain obvious, at a 
glance.

I could have concatenated the first subject line with the impact 
information:

 27b1956: lockdep: warn about lockdep disabling after kernel taint, fix build error on Sparc and s390

... but this is clearly over-long and dillutes the subject line with 
'effect' information.

	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/