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:
signature.asc
Description: PGP signature
