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. thanks -- PMM
