Date:   Thu, 9 Mar 2023 09:25:54 -0800
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 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.

> It'd be easier to just have multi-arch series use a stable base (i.e. a
> release candidate) by default. That'd avoid the undesirable case where merging
> a shared branch brings with it some random point in another arch's /next
> history.

You're conflating the base of the patch series with the branch it is applied to.
I'm most definitely not proposing that multi-arch series from x86 contributors
always be routed through kvm-x86.  It's ultimately the responsibility of the
maintainers, not the contributors, to avoid funky merges and histories.  If a
series warrants a dedicated topic branch, then we need to create said topic branch
off a stable, common base, irrespective of what the contributor based their patches
on.

If a series from an x86 contributor applies cleanly on kvm-x86/next but not on
-rc2 (or whatever), then the reverse would also likely be true (if the contributor
used -rc2 as the base).  In other words, for series with non-trivial modifications
to other architectures and/or common KVM code, IMO the base used for the _initial_
posting doesn't matter all that much for us maintainers since such series will
likely require additional attention no matter what base is used.

On the flip side, the vast majority of "multi-arch" series in KVM tend to be focused
on a single architecture, with only incidental contact to other architectures and/or
common KVM code.  Those types of series will likely be routed through their "target"
arch tree, and so for x86, using kvm-x86/next as the base is preferrable.

My goal with suggesting/prescribing kvm-x86/next to contributors is to make the
easy things easy.  On my end, that means having _predictable_ submissions and
minimizing the number of avoidable conflicts.  For contributors, that means having
a very simple rule/guideline.  "Use kvm-x86/next unless you know better" satisfies
all those conditions.

> If a different approach makes sense for a particular series then we can
> discuss it on the list and arrive at something agreeable for all parties
> involved.
> 
> > 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.

Powered by blists - more mailing lists