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. > > 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. > > You're conflating the base of the patch series with the branch it is applied to. We cannot pretend the two are in no way related. The dependencies of a series are not obvious when based on the /next branch of any one architecture. > I'm most definitely not proposing that multi-arch series from x86 contributors > always be routed through kvm-x86. It's ultimately the responsibility of the > maintainers, not the contributors, to avoid funky merges and histories. Right, but contributors looking to make changes across architectures share some of the burden of cross-arch coordination as well. Basing patches off of a random commit not in Linus' tree does not match at least the arm64 workflow. > If a > series warrants a dedicated topic branch, then we need to create said topic branch > off a stable, common base, irrespective of what the contributor based their patches > on. The lowest friction way to coordinate such things is to start off with a common base and go from there. If there is a compelling argument for doing things differently in the context of one series then let's talk about it on the list. > If a series from an x86 contributor applies cleanly on kvm-x86/next but not on > -rc2 (or whatever), then the reverse would also likely be true (if the contributor > used -rc2 as the base). This can be addressed in a merge resolution, thereby offloading the responsibility to the maintainer. > In other words, for series with non-trivial modifications > to other architectures and/or common KVM code, IMO the base used for the _initial_ > posting doesn't matter all that much for us maintainers since such series will > likely require additional attention no matter what base is used. In all likelihood, sure the series will be respun. But, you're offloading the responsibility to ask for a sane base on other arch maintainers which I'm not cool with. > On the flip side, the vast majority of "multi-arch" series in KVM tend to be focused > on a single architecture, with only incidental contact to other architectures and/or > common KVM code. Those types of series will likely be routed through their "target" > arch tree, and so for x86, using kvm-x86/next as the base is preferrable. With long term aspirations to share more code between architectures (e.g. common MMU) I believe we'll see more changes that have meaningful interaction with all architecutures. > My goal with suggesting/prescribing kvm-x86/next to contributors is to make the > easy things easy. On my end, that means having _predictable_ submissions and > minimizing the number of avoidable conflicts. For contributors, that means having > a very simple rule/guideline. "Use kvm-x86/next unless you know better" satisfies > all those conditions. I believe "Use a release candidate unless you know better" for multi-arch changes is just as simple. Better yet, it clues in contributors as to how changes are coordinated across architectures and might help them know better next time around. > > 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. > > +<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. -- Thanks, Oliver
