Messages in this thread | | | Date | Wed, 15 Apr 2009 22:22:08 -0400 | Subject | Re: Fix quilt merge error in acpi-cpufreq.c | From | Paul Gortmaker <> |
| |
On Wed, Apr 15, 2009 at 10:00 PM, Rusty Russell <rusty@rustcorp.com.au> wrote: > On Thu, 16 Apr 2009 04:17:49 am H. Peter Anvin wrote: >> Linus Torvalds wrote: >> "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. > > Side note: I really prefer to see the compile error output in this case: great > for googling. It annoys me when people skip this. > > Anyway, Impact: had lead me to think harder about my messages than the > free-form commit style did. Perhaps it's too rigid, but it helped. > > Let's get concrete. Here's the top 3 non-merge commits in gitk: > > ALSA: hda - Fix the cmd cache keys for amp verbs > > Fix the key value generation for get/set amp verbs. The upper bits of > the parameter have to be combined with the verb value to be unique for > each direction/index of amp access. > > This fixes the resume problem on some hardwares like Macbook after > the channel mode is changed. > > I have no idea what this patch does. It seems to be a fix; what are the > symptoms of the problem, and how long has it been there? > > ALSA: add missing definitions(letters) to HD-Audio.txt > > impact: Add missing definitions(letters). > > This is actually a pure documentation patch. "Fix typos" or "Documentation > fixes" would seem sufficient for subject, and no body needed. > > ALSA: sound/pci: use memdup_user() > > Remove open-coded memdup_user(). > > Again, the body seems gratuitous. > > Anyone want to try to write a guide on writing good commit messages?
I'd put together some notes on making good commit messages for internal use, trying to guide people into describing the symptoms of a problem and why what is being submitted is the correct technical fix -- vs. the semi-useless cop-outs of an English translation of the C code itself (i.e. "increment foo comparison by one" or similar).
It isn't anything near a big wordy guide in its own right (and hopefully it doesn't need to be), but I'm willing to use it as a start, plus bits from this discussion, and once folks agree on the content I put together being OK, we can stick it in Documentation SubmittingPatches or wherever seems appropriate. Assuming people in general think there is a need for it...
Paul.
> Rusty. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |