On Mon, Mar 13, 2023, Oliver Upton wrote: > On Thu, Mar 09, 2023 at 09:25:54AM -0800, Sean Christopherson wrote: > > 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. > > Sorry, I follow this reasoning at all. > > If folks are aiming to make a multi-arch contribution then the architecture > they regularly contribute to has absolutely zero relevance on the series > itself. There's disconnect between what my brain is thinking and what I wrote. The intent of the "use kvm-x86/next" guideline is aimed to address series that are almost entirely x86 specific, and only superficially touch common KVM and/or other architectures. In my experience, the vast, vast majority of "multi-arch" contributions from x86 fall into this category, i.e. aren't truly multi-arch in nature. If I replace the above paragraph with this, does that address (or at least mitigate to an acceptable level) your concerns? Inevitably there will still be series that are wrongly based on kvm-x86, but I am more than happy to do the policing. I obviously can't guarantee that I will be the first to run afoul of a "bad" series, but I do think I can be quick enough to avoid shifting the burden to other maintainers. And if I'm wrong on either front, you get to say "told you so" and make me submit a patch of shame ;-) The only exception to using ``kvm-x86/next`` as the base is if a patch/series is a multi-arch series, i.e. has non-trivial modifications to common KVM code and/or has more than superficial changes to other architectures's code. Multi- arch patch/series should instead be based on a common, stable point in KVM's history, e.g. the release candidate upon which ``kvm-x86 next`` is based. If you're unsure whether a patch/series is truly multi-arch, err on the side of caution and treat it as multi-arch, i.e. use a common base. > > > > 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. > > You've also made some suggestions about cross-arch development that do not fit > the development model of other architectures. I have no desire to nitpick > about the x86 process but want the multiarch language to actually set folks up > for success working outside of the KVM/x86 tree. Ah, I see where y'all are coming from. Yeah, I didn't intend for that type of blanket rule, e.g. my comment about this being specifically for KVM x86 was intended to clarify that this doc should NOT be used to determine how to handle non-x86 code.
