Re: [PATCH 3/4] tracing/branch-tracer: Fix a trace recursion on branch tracer

[Ingo Molnar <mingo@elte.hu>]

* Jonathan Corbet <corbet@lwn.net> wrote:

> On Sun, 16 Nov 2008 15:01:24 +0100
> "Frédéric Weisbecker" <fweisbec@gmail.com> 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:

   http://lkml.org/lkml/2008/10/28/67

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 
solves.

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 :-)

	Ingo