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

[Oliver Upton <oliver.upton@linux.dev>]

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.

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.

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.

Patches aimed at KVM/arm64 should be based on a sensible release candidate.
We tend to contstruct the kvmarm/next with an early-ish release candidate
(rc2-rc4). For example the 6.3 pull request was based on 6.2-rc4. We use topic
branches in a slightly different manner than x86, creating ad-hoc branches for
individual patch series grabbed from the list.

If one has a series that conflicts with/depends on another that is in-flight
or already picked up then that should be mentioned in the cover letter.
Ultimately its up to the maintainer(s) to address conflicts, and neither
Marc nor I are afraid to ask for a rebase/respin if it makes our lives
easier to glue it all together.

-- 
Thanks,
Oliver