Messages in this thread | | | Date | Mon, 17 Nov 2008 12:30:23 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 3/4] tracing/branch-tracer: Fix a trace recursion on branch tracer |
| |
* 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 -- 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/
| |