On 6/25/2026 6:37 PM, Alistair Francis wrote: > 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. >
I agree it does not scale. It creates friction both for you and people who submit in the subsystem. >> >> 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. > Then simply apply a FIFO strategy. Take series as they come, and leave conflicting one out. IMHO, it should not be the responsibility of a maintainer. >> >> 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. > How about merging things to master fast enough so people can just rebase on master? It seems like it would solve both people problems, and yours also. No need to do any rebase, and no wait time for developers. The only thing it requires is to increase PR frequency, and I would even go as far as suggesting to send one PR per series if you want to provide the best velocity possible for this subsystem. Just automate the push and CI triggering, so it does not take more than 2 min of your time. When a conflict happen or a test fail, simply ask "please rebase/fix", and wait for the next version. Not your problem anymore. What do you think? > 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 >> >> Regards, Pierrick
