[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.052 / U:2.888 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site