Re: [PATCH v3 00/23] perf: Add infrastructure and support for Intel PT

[Ingo Molnar <mingo@kernel.org>]

* Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote:

> Hi Peter and all,
> 
> Here's a new version of PT support patchset, this time including PT and
> BTS drivers and a few more tweaks to the core. I still left out some bits
> like core dump support for now. Tooling support is not included in this
> series so that it's easier to review the kernel bits, I suppose it's best
> to send it separately, since it's quite a huge patchset of its own.

I know what this series is about, but pretty please, always include a 
complete introduction, or at least a link to a good introdcution, 
which spells out the whole problem space, the proposed solution, its 
various design trade-offs (if any), links to tooling for people who 
want to have a look at both sides, list of items not yet properly 
implemented [or a clear statement that it's all ready to go in your 
view], etc., in as much detail as possible!

The reason is that many reviewers will skip early versions of patch 
series, especially if they see something trivially objectionable in 
it. Why spend effort on reviewing something that might never see the 
light of the day? But if later re-sends of the series skip essential 
information it's harder to 'jump in' and offer useful feedback...

If you worry about being overly verbose in your patch series 
announcement, in my experience as a kernel maintainer it's literally 
impossible for kernel developers to over-do the description of a new 
feature. (Steve Rostedt tries on occasion but even he never succeeded 
in the past. I claim this is due to software developer brain 
structure, but I digress.)

It's also absolutely fine to cut & paste an old 0/N description over 
and over again, and to update it only as far as the patches have 
changed.

A good rule of thumb is to have at least as many sentences in the 0/N 
description as there are patches in the series, i.e. 23 sentences in 
this instance. Preferably scaled up by complexity.

Thanks,

	Ingo