lkml.org 
[lkml]   [2009]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Fix quilt merge error in acpi-cpufreq.c
    From
    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/

    \
     
     \ /
      Last update: 2009-04-16 04:31    [W:0.025 / U:32.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site