[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZAlGeYAmvhPmVmGe@debian.me>
Date: Thu, 9 Mar 2023 09:37:45 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>
Cc: 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>,
Oliver Upton <oliver.upton@...ux.dev>,
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 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.
That means patches that primarily kvm ARM changes should be based on
kvm-x86/next, right?
> +If a patch touches multiple topics, traverse up the conceptual tree to find the
> +first common parent (which is often simply ``x86``). When in doubt,
> +``git log path/to/file`` should provide a reasonable hint.
What do you mean by conceptual tree? Is it Patch subject prefix?
> +KVM selftests that are associated with KVM changes, e.g. regression tests for
> +bug fixes, should be posted along with the KVM changes as a single series. The
> +standard kernel rules for bisection apply, i.e. KVM changes that result in test
> +failures should be ordered after the selftests updates, and vice versa, new
> +tests that fail due to KVM bugs should be ordered after the KVM fixes.
Did you mean that in a patch series, selftest patches are placed after
their corresponding KVM changes?
Thanks.
--
An old man doll... just what I always wanted! - Clara
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists