On Tue, Jun 23, 2026 at 9:39 PM Daniel Henrique Barboza <[email protected]> wrote: > > > > On 6/23/2026 6:58 AM, Peter Maydell wrote: > > On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza > > <[email protected]> wrote: > >> > >> > >> > >> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote: > >>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote: > >>>> On 22/6/26 22:52, Pierrick Bouvier wrote: > >>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote: > >>>>>> Hello, > >>>>>> > >>>>>> This series looks scary but it's mostly trivial and mechanical work. > >>>>>> > >>>>>> It is yet another attempt at fixing --disable-tcg. We have a recent > >>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2]. > >>>>>> Phil's work didn't get merged and it's now too hard to rebase and > >>>>>> revive, the most recent attempt got misled into the 'what is common > >>>>>> code > >>>>>> between TCG and KVM' dungeon. > >>>> > >>>> > >>>>> It seems like series does not apply on top of master, would that be > >>>>> possible to rebase it? > >>>> > >>>> For some reason the RISC-V series are handled distinctly than the > >>>> rest of QEMU, Alistair queues work on his repository and developers > >>>> are custome to base their series on top of it (otherwise Alistair > >>>> can not apply them on his tree and asks for reposts), see the > >>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu. > >>> > >>> Unfortunately, it makes it hard to run any kind of automated testing, > >>> especially for series like this that target specific configs. > >> > >> Don't we have ways of saying in the commit message "these patches applies > >> on top of these other patches" and then the tooling would deal with it? > >> I remember patchew doing stuff like that with that "Based-on: <message-id>" > >> tag. > > > > Yes, Based-on: is our convention for marking "this patchset needs some > > other one to be applied first". But that should be the exception rather > > than a common case -- if patchsets regularly need to be based on > > something other than head-of-git, this is I think a sign that > > maintainers are not sending out pull requests frequently enough. > > > > I would prefer it if QEMU didn't develop kernel-style "subsystems > > have their own particular workflows" fragmentation -- I don't > > think we're big enough or that sub-parts of QEMU are sufficiently > > well separated for it to work out well. > > I agree that rebasing things on master is better than rebasing it on the > maintainer's tree. And we could make a better job at informing developers > that > submitting a patch for qemu-riscv, vfio or any particular subtree, means that > the patch should be based on a maintainer tree X.
I would prefer patches on master, the issue is it just creates a lot of conflicts. That takes time for me to fix and I'm always worried that I'll mess something up and it will go upstream with a bug that wasn't in the original patch because no one gets a chance to verify that I rebased it correctly. > > The thing is that sending patches on master only works if master is always up > to date, and that's not feasible with our current style of merging PRs. This > series we're commenting on is an example: it doesn't apply to master because > there are pre-approved RISC-V patches in the maintainer's tree from 2 days ago > (also my patches, I might add) that caused conflicts that I wasn't aware that > would happen. This conflict would have to be dealt with at some point by > myself > or the maintainer, and it's not like 2 days is too much time without a PR. Yeah, I try to send them every few weeks, but when all the patches are touching the same few files it's hard not to hit conflicts. > > We can argue "this is an exception that doesn't happen that often, we should > stick with using master as a base", and to a certain extend that's true. But > then this sort of conflict happens again, then again, then again, it comes to > a point where it's easier to tell developers to use the maintainer's tree > instead > of master. Which is exactly what happened. I think I have just asked people to rebase on the RISC-V tree enough times that they just start with that from the beginning. Alistair > > Maybe I'm downplaying the problem because I've been sending stuff based on the > maintainer's tree since forever and got used to it. IMO, unless we decide to > be > like libvirt and create the "committer" role to allow trustworthy devs to push > stuff to master after acks, making it more feasible to expect master to be up > to > date, I'm afraid we're closer to a kernel-style workflow. For better or > worse. > > > Thanks, > Daniel > > > > > > thanks > > -- PMM > >
