public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dave Jones <davej@redhat.com>
Subject: Re: Fix quilt merge error in acpi-cpufreq.c
Date: Wed, 15 Apr 2009 22:31:03 -0400	[thread overview]
Message-ID: <20090416023103.GI21586@mit.edu> (raw)
In-Reply-To: <200904161057.07108.rusty@rustcorp.com.au>

On Thu, Apr 16, 2009 at 10:57:05AM +0930, Rusty Russell wrote:
> Ingo wants them.  Example:
> 
> 	lguest: don't expect linear addresses in gdt pvops
> 
> 	Impact: fix guest crash 'lguest: bad read address 0x4800000 len 256'
> 
> What's more important in the subject line?  That it fixes a crash, or what it
> does?

Well, consider that 2 or 3 months later, when we're trying to find a
potential commit (say, because we're trying to find a potential fix
that needs to be forward ported to a distro kernel, or some such), the
initial summary line is what is going to be visible in gitk or via
"git log --oneline" (or "git log --pretty=oneline --abbrev-commit" for
older git versions).

So when I try to create git log messages, I try to make the first line
useful for folks who might be sorting through potentially thousands of
patches via gitk or git log --oneline.  So I might do something like

lguest: fix crash caused by expecting linear address in gdt pvops

and then making sure the body of the message goes into detail about
the oops message so that someone who is searching "git log" might find
the commit.  I also try to include relevant bugzilla numbers (for
distro's as well as the kernel bugzilla system).[1]

I think it was you who once quoted Will Strunk, "Always write with
deep sympathy for the reader"?  This definitely applies to git commit
messages, both the initial one-line summary as well as the body.

[1] I tend to use "Addresses-Debian-bug: #12345" in e2fsprogs git
repository, but the convention in the kernel commit logs seems to be
to use the URL to the bugzilla entry.  Since it's stuff that's
intended to be grep'ed, I put it at the end of the commit body, just
before the Signed-off-by: messages.

						- Ted

P.S.  One thing wihch I'd like to suggest is for folks to use "fix
lock ordering" instead of "fix lockdep warning".  I've been guilty of
using "lockdep warning" mmyself, and I've realized that when searching
to see if a reported hang might have been fixed, the brain has a
tendency to skip over a summary line that says "warning"; and a commit
that fixes a lockdep warning is more serious, than say, for example,
fixing some whining warning message from gcc.

  reply	other threads:[~2009-04-16  2:31 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200904140159.n3E1x1K1014705@hera.kernel.org>
2009-04-14  2:05 ` Fix quilt merge error in acpi-cpufreq.c Ingo Molnar
2009-04-15  5:44   ` Ingo Molnar
2009-04-15 10:44     ` Rusty Russell
2009-04-15 15:28       ` Linus Torvalds
2009-04-15 16:26         ` Ingo Molnar
2009-04-15 16:46           ` H. Peter Anvin
2009-04-15 17:00             ` H. Peter Anvin
2009-04-15 17:19           ` Linus Torvalds
2009-04-15 18:47             ` H. Peter Anvin
2009-04-15 19:43               ` Linus Torvalds
2009-04-15 20:07                 ` Ingo Molnar
2009-04-15 20:32                 ` Andrew Morton
2009-04-15 21:03                   ` Ingo Molnar
2009-04-15 21:15                     ` Linus Torvalds
2009-04-15 22:40                       ` Ingo Molnar
2009-04-15 23:08                         ` Linus Torvalds
2009-04-16  0:08                           ` Ingo Molnar
2009-04-16  0:23                             ` Linus Torvalds
2009-04-16  0:38                               ` Linus Torvalds
2009-04-16  0:50                                 ` Ingo Molnar
2009-04-16  4:33                                   ` H. Peter Anvin
2009-04-16  7:14                                     ` Ingo Molnar
2009-04-16 15:24                                   ` Valdis.Kletnieks
2009-04-15 23:49                       ` David Miller
2009-04-16 11:00                         ` Christoph Hellwig
2009-04-15 21:17                     ` Andrew Morton
2009-04-15 23:04                       ` Ingo Molnar
2009-04-15 21:23                 ` David Miller
2009-04-15 22:48                   ` Ingo Molnar
2009-04-15 23:11                     ` Linus Torvalds
2009-04-16  0:44                       ` Ingo Molnar
2009-04-16  1:03                         ` Linus Torvalds
2009-04-16  1:46                           ` Ingo Molnar
2009-04-16  2:22                             ` Linus Torvalds
2009-04-16  7:23                               ` Ingo Molnar
2009-04-16  3:55                             ` Theodore Tso
2009-04-16  7:44                               ` Ingo Molnar
2009-04-16 15:41                             ` Valdis.Kletnieks
2009-04-16 13:04                   ` Valdis.Kletnieks
2009-04-16  2:00               ` Rusty Russell
2009-04-16  2:22                 ` Paul Gortmaker
2009-04-16  2:34                 ` Linus Torvalds
2009-04-16  3:10                 ` Ray Lee
2009-04-16  7:56                 ` Ingo Molnar
2009-04-16 11:57                   ` Theodore Tso
2009-04-16 13:55                 ` Jonathan Corbet
2009-04-20  8:14                   ` Rusty Russell
2009-04-20 10:38                     ` Ingo Molnar
2009-04-22  4:18                       ` Rusty Russell
2009-04-21 19:37                     ` Jonathan Corbet
2009-04-22  1:58                       ` Rusty Russell
2009-04-16  1:27         ` Rusty Russell
2009-04-16  2:31           ` Theodore Tso [this message]
2009-04-16  8:02             ` Ingo Molnar
2009-04-15 15:05     ` Linus Torvalds
2009-04-15 15:22       ` Ali Gholami Rudi
2009-04-15 16:41       ` Ingo Molnar
     [not found] <crh66-6nQ-7@gated-at.bofh.it>
     [not found] ` <crilu-8hM-13@gated-at.bofh.it>
     [not found]   ` <crjhu-1lb-13@gated-at.bofh.it>
     [not found]     ` <crkQl-3QL-7@gated-at.bofh.it>
     [not found]       ` <crm5K-5NR-17@gated-at.bofh.it>
     [not found]         ` <crmyK-6DP-9@gated-at.bofh.it>
     [not found]           ` <crnXV-g5-27@gated-at.bofh.it>
     [not found]             ` <croh9-VK-5@gated-at.bofh.it>
     [not found]               ` <croTQ-1Jm-1@gated-at.bofh.it>
     [not found]                 ` <crqVM-4UC-11@gated-at.bofh.it>
2009-04-16  5:46                   ` Niel Lambrechts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090416023103.GI21586@mit.edu \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox