Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Tue, 19 Sep 2023 08:37:27 -0700
In-Reply-To: <196a645c-f41d-8f35-d854-f30b66aff2a6@xen.org>
Mime-Version: 1.0
References: <20230918144111.641369-1-paul@xen.org> <ZQh4Zi5Rj3RP9Niw@google.com>
 <8527f707315812d9ac32201b37805256fab4a0a1.camel@infradead.org>
 <ZQiE7SExjbCVffAE@google.com> <196a645c-f41d-8f35-d854-f30b66aff2a6@xen.org>
Message-ID: <ZQnAN9TC6b8mSJ/t@google.com>
Subject: Re: [PATCH v3 00/13] KVM: xen: update shared_info and vcpu_info handling
From:   Sean Christopherson <seanjc@google.com>
To:     paul@xen.org
Cc:     David Woodhouse <dwmw2@infradead.org>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Paul Durrant <pdurrant@amazon.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, x86@kernel.org
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Tue, Sep 19, 2023, Paul Durrant wrote:
> On 18/09/2023 18:12, Sean Christopherson wrote:
> [snip]
> > 
> > Tag them RFC, explain your expectations, goals, and intent in the cover letter,
> > don't copy+paste cover letters verbatim between versions, and summarize the RFC(s)
> > when you get to a point where you're ready for others to jump in.  The cover
> > letter is *identical* from v1=>v2=>v3, how is anyone supposed to understand what
> > on earth is going on unless they happened to be in the same room as ya'll on
> > Friday?
> 
> The cover letter is indeed identical because the purpose of the series has
> not changed.

For anything out of the ordinary, e.g. posting v3 just a few hours after v2 is
definitely not normal, use the cover letter to call out why you're posting a
particular version of the series, not just the purpose of the series.  

> > In other words, use tags and the cover letter to communicate, don't just view the
> > cover letter as a necessary evil to get people to care about your patches.
> 
> That was not the intention at all; I put all the detailed explanation in the
> commit comments because I thought that would make review *easier*.

Per-patch comments *might* make individual patches easier to review, but (for me
at least) they are waaay less helpful for reviewing series as a whole, and all
but usless for initial triage.  E.g. for a situation like this where a series
has reached v4 before I've so much as glanced at the patches, having the history
in the cover letter allows me to catch up and get a feel for how the series got
to v4 in ~20 seconds.  With per-patch comments, I have to go find each comment
and then piece together the bigger picture.

Per-patch comments also don't work well if a version makes minor changes to a
large series (hunting through a 10+ patch series to figure out that only one patch
changed is not exactly efficient), if a patch is dropped, if there are changes to
the overall approach, etc.