[lkml]   [2008]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 3/4] tracing/branch-tracer: Fix a trace recursion on branch tracer

    * Jonathan Corbet <> wrote:

    > On Sun, 16 Nov 2008 15:01:24 +0100
    > "Frédéric Weisbecker" <> wrote:
    > > Ok. Yeah I had some trouble with this "impact" tag, finding it hard to
    > > not overlap its message with this of the patch's subject but I better
    > > understand now...
    > > Perhaps this tag should be explained in
    > > Documentation/development-process/5.Posting and SubmittingPatches...
    > > (cc-ed Jonathan for the development-process documents)....

    this is really only an experimental tag at this point, and not
    mandatory in any way.

    > I'll happily do so. I will confess, though, that I don't really
    > understand how that tag differs from the information which simply
    > belongs in the patch title and changelog.

    The impact line (invented by hpa half a year ago and used by the x86
    maintainers for the past couple of months) tries to give a one-line
    "impact of change" risk summary.

    Here's a small description about it:

    the impact line is a secondary subject line, it quantifies practical
    impact of changes/bugfixes.

    The subject line is often controlled by other principles (subsystem
    tags, scope and subject of change, etc.), and the actual changelog is
    often very verbose and talks about the change, not just the problem it

    The impact-line also documents the _intended_ impact of a change -
    making it easier to see it later whether a change was contemplated to
    have side-effects originally. If a change says "Impact: cleanup" and
    it turns out to break some systems later on, the discrepancy is very
    clear and well documented. We had cases already where it helped.

    It also helps when maintaining changes: it makes it clear whether a
    patch should be backported to -stable, etc. Filtering through
    thousands of changes in search for fixes that matter can be quite hard
    - the impact line helps speed up that workflow too.

    The definition and usage if it is still a bit in flux, so i'm not sure
    we want to codify it in Documentation/SubmittingPatches. But if you
    could come up with a description it would at minimum be a nice URL to
    point contributors to :-)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2008-11-17 12:33    [W:0.029 / U:87.976 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site