Re: [PATCH v2 2/2] Documentation/process: Add a maintainer handbook for KVM x86

[Bagas Sanjaya <bagasdotme@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]