Date:   Mon, 13 Mar 2023 11:20:45 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Oliver Upton <oliver.upton@...ux.dev>
Cc:     Bagas Sanjaya <bagasdotme@...il.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Sagi Shahar <sagis@...gle.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Peter Shier <pshier@...gle.com>,
        Anish Ghulati <aghulati@...gle.com>,
        James Houghton <jthoughton@...gle.com>,
        Anish Moorthy <amoorthy@...gle.com>,
        Ben Gardon <bgardon@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Ricardo Koller <ricarkol@...gle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Aaron Lewis <aaronlewis@...gle.com>,
        Ashish Kalra <ashish.kalra@....com>,
        Babu Moger <babu.moger@....com>, Chao Gao <chao.gao@...el.com>,
        Chao Peng <chao.p.peng@...ux.intel.com>,
        Chenyi Qiang <chenyi.qiang@...el.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        Gavin Shan <gshan@...hat.com>,
        Guang Zeng <guang.zeng@...el.com>,
        Hou Wenlong <houwenlong.hwl@...group.com>,
        Jiaxi Chen <jiaxi.chen@...ux.intel.com>,
        Jim Mattson <jmattson@...gle.com>,
        Jing Liu <jing2.liu@...el.com>,
        Junaid Shahid <junaids@...gle.com>,
        Kai Huang <kai.huang@...el.com>,
        Leonardo Bras <leobras@...hat.com>,
        Like Xu <like.xu.linux@...il.com>,
        Li RongQing <lirongqing@...du.com>,
        "Maciej S . Szmigiero" <maciej.szmigiero@...cle.com>,
        Maxim Levitsky <mlevitsk@...hat.com>,
        Michael Roth <michael.roth@....com>,
        Michal Luczaj <mhal@...x.co>,
        Mingwei Zhang <mizhang@...gle.com>,
        Nikunj A Dadhania <nikunj@....com>,
        Paul Durrant <pdurrant@...zon.com>,
        Peng Hao <flyingpenghao@...il.com>,
        Peter Gonda <pgonda@...gle.com>, Peter Xu <peterx@...hat.com>,
        Robert Hoo <robert.hu@...ux.intel.com>,
        Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Vipin Sharma <vipinsh@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Wei Wang <wei.w.wang@...el.com>,
        Xiaoyao Li <xiaoyao.li@...el.com>,
        Yu Zhang <yu.c.zhang@...ux.intel.com>,
        Zhenzhong Duan <zhenzhong.duan@...el.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] Documentation/process: Add a maintainer handbook
 for KVM x86

On Mon, Mar 13, 2023, Oliver Upton wrote:
> On Thu, Mar 09, 2023 at 09:25:54AM -0800, Sean Christopherson wrote:
> > On Thu, Mar 09, 2023, Oliver Upton wrote:
> > > On Thu, Mar 09, 2023 at 09:37:45AM +0700, Bagas Sanjaya wrote:
> > > > On Wed, Mar 08, 2023 at 05:03:36PM -0800, Sean Christopherson wrote:
> > > > > +As a general guideline, use ``kvm-x86/next`` even if a patch/series touches
> > > > > +multiple architectures, i.e. isn't strictly scoped to x86.  Using any of the
> > > > > +branches from the main KVM tree is usually a less good option as they likely
> > > > > +won't have many, if any, changes for the next release, i.e. using the main KVM
> > > > > +tree as a base is more likely to yield conflicts.  And if there are non-trivial
> > > > > +conflicts with multiple architectures, coordination between maintainers will be
> > > > > +required no matter what base is used.  Note, this is far from a hard rule, i.e.
> > > > > +use a different base for multi-arch series if that makes the most sense.
> > > 
> > > I don't think this is the best way to coordinate with other architectures.
> > > Regardless of whether you intended this to be prescriptive, I'm worried most
> > > folks will follow along and just base patches on kvm-x86/next anyway.
> > 
> > Probably, but for the target audience (KVM x86 contributors), that's likely the
> > least awful base 99% of the time.
> 
> Sorry, I follow this reasoning at all.
> 
> If folks are aiming to make a multi-arch contribution then the architecture
> they regularly contribute to has absolutely zero relevance on the series
> itself.

There's disconnect between what my brain is thinking and what I wrote.

The intent of the "use kvm-x86/next" guideline is aimed to address series that
are almost entirely x86 specific, and only superficially touch common KVM and/or
other architectures.  In my experience, the vast, vast majority of "multi-arch"
contributions from x86 fall into this category, i.e. aren't truly multi-arch in
nature.

If I replace the above paragraph with this, does that address (or at least mitigate
to an acceptable level) your concerns?  Inevitably there will still be series that
are wrongly based on kvm-x86, but I am more than happy to do the policing.  I
obviously can't guarantee that I will be the first to run afoul of a "bad" series,
but I do think I can be quick enough to avoid shifting the burden to other
maintainers.  And if I'm wrong on either front, you get to say "told you so" and
make me submit a patch of shame ;-)

  The only exception to using ``kvm-x86/next`` as the base is if a patch/series
  is a multi-arch series, i.e. has non-trivial modifications to common KVM code
  and/or has more than superficial changes to other architectures's code.  Multi-
  arch patch/series should instead be based on a common, stable point in KVM's
  history, e.g. the release candidate upon which ``kvm-x86 next`` is based.  If
  you're unsure whether a patch/series is truly multi-arch, err on the side of
  caution and treat it as multi-arch, i.e. use a common base.

> > > > That means patches that primarily kvm ARM changes should be based on
> > > > kvm-x86/next, right?
> > > 
> > > No, don't do that.
> > 
> > +<infinity symbol>
> > 
> > This doc is specifically for KVM x86.
> 
> You've also made some suggestions about cross-arch development that do not fit
> the development model of other architectures. I have no desire to nitpick
> about the x86 process but want the multiarch language to actually set folks up
> for success working outside of the KVM/x86 tree.

Ah, I see where y'all are coming from.  Yeah, I didn't intend for that type of
blanket rule, e.g. my comment about this being specifically for KVM x86 was
intended to clarify that this doc should NOT be used to determine how to handle
non-x86 code.

Powered by blists - more mailing lists