Looking at the merges for the last year:

  $ git shortlog --merges --since "last year" *-user/ accel/tcg/user-exec* hw/core/cpu-user.c include/user/ scripts/qemu-binfmt-conf.sh scripts/update-syscalltbl.sh scripts/update-mips-syscall-args.sh tests/functional/arm/test_bflt.py tests/vm/*bsd

  Richard Henderson (4):
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'pull-tcg-20251019' of https://gitlab.com/rth7680/qemu into staging

  Stefan Hajnoczi (12):
        Merge tag 'linux-user-fix-gupnp-pull-request' of https://github.com/hdeller/qemu-hppa into staging
        Merge tag 'pull-10.0-testing-and-gdstub-updates-100225-1' of https://gitlab.com/stsquad/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'pull-loongarch-20250424' of https://github.com/gaosong715/qemu into staging
        Merge tag 'pull-misc-2025-04-24' of https://repo.or.cz/qemu/armbru into staging
        Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
        Merge tag 'hppa-fpe-fixup-pull-request' of https://github.com/hdeller/qemu-hppa into staging
        Merge tag 'pull-target-arm-20250704' of https://gitlab.com/pm215/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'pull-10.1-rc0-maintainer-140725-1' of https://gitlab.com/stsquad/qemu into staging
        Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging
        Merge tag 'accel-20250715' of https://github.com/philmd/qemu into staging

None of the pull requests have come through the maintainers and while
there are a fair number of commits overall they have been mostly bug
fixes, re-factoring clean-ups and the occasional new syscall/ioctl
handling.

We should reflect the current status so users don't have unrealistic
expectations of how quickly things can get reviewed and merged.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---

[AJB] I realise this is a slightly provocative patch but given how
widely used *-user is downstream we should be clear about the current
state and hopefully encourage those who rely on it to step-up.
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ee64a528c7f..1f313bba84f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4016,7 +4016,7 @@ Usermode Emulation
 ------------------
 Overall usermode emulation
 M: Riku Voipio <riku.voipio@iki.fi>
-S: Maintained
+S: Odd Fixes
 F: accel/tcg/user-exec*.c
 F: hw/core/cpu-user.c
 F: include/user/
@@ -4025,7 +4025,7 @@ F: common-user/
 BSD user
 M: Warner Losh <imp@bsdimp.com>
 R: Kyle Evans <kevans@freebsd.org>
-S: Maintained
+S: Odd Fixes
 F: bsd-user/
 F: configs/targets/*-bsd-user.mak
 F: tests/vm/*bsd
@@ -4034,7 +4034,7 @@ T: git https://github.com/qemu-bsd-user/qemu-bsd-user bsd-user-rebase-3.1
 Linux user
 M: Laurent Vivier <laurent@vivier.eu>
 R: Pierrick Bouvier <pierrick.bouvier@linaro.org>
-S: Maintained
+S: Odd Fixes
 F: linux-user/
 F: configs/targets/*linux-user.mak
 F: scripts/qemu-binfmt-conf.sh
-- 
2.47.3

On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> We should reflect the current status so users don't have unrealistic
> expectations of how quickly things can get reviewed and merged.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>

Reviewed-by: Warner Losh <imp@bsdimp.com>


> ---
>
> [AJB] I realise this is a slightly provocative patch but given how
> widely used *-user is downstream we should be clear about the current
> state and hopefully encourage those who rely on it to step-up.
>

For the bsd-user case this is likely correct. We run hot and cold about
being
proactive at fixing things, and we've been somewhat cold for a while now.

Part of the problem is that this submission process is very very heavyweight
compared to other projects I contribute to. Not sure what to do about that
since
there's a reluctance to move away from it. Or alternatively, I'm somehow
making
it too hard.

A lot of the upstreaming work that's stalled would be ideal to tell claude
to do,
but I'm unsure the project's stance on using claude to move code, and git
log
5 different trees to get the original author(s) of the code and make
trivial compile
tweaks.

Warner

On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote:
> On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org> wrote:
> 
> > We should reflect the current status so users don't have unrealistic
> > expectations of how quickly things can get reviewed and merged.
> >
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >
> 
> Reviewed-by: Warner Losh <imp@bsdimp.com>

snip
 
> A lot of the upstreaming work that's stalled would be ideal to tell claude
> to do,
> but I'm unsure the project's stance on using claude to move code, and git
> log
> 5 different trees to get the original author(s) of the code and make
> trivial compile
> tweaks.

The critical thing we don't want is such tools making changes to the
contents of source files.

Automating the moving around of files is a non-issue.

The use of AI for writing commit messages is arguably in scope of QEMU's
AI policy given that is part of "the contribution", but it is less serious
there, since commit messages don't have a copyright implication on what we
host & distribute.

More important is that the commit messages are accurate and well written.
LLMs have a tendancy to be overly verbose about irrelevant stuff, and of
course the well known danger of hallucinating nonsense. IME that makes it
challenging to benefit from an LLM, due to review & re-writing overheads
you then incurr to validate and fix their output.

I'd be wary of relying on an AI to extract and report on authorship of
code. Accuracy is important there since it implies copyright ownership
associations. Likewise a Signed-off-by tag should be added by humans
only since it is a statement they are complying with the DCO policy.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Fri, Jan 23, 2026 at 9:58 AM Daniel P. Berrangé <berrange@redhat.com>
wrote:

> On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote:
> > On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> > > We should reflect the current status so users don't have unrealistic
> > > expectations of how quickly things can get reviewed and merged.
> > >
> > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > >
> >
> > Reviewed-by: Warner Losh <imp@bsdimp.com>
>
> snip
>
> > A lot of the upstreaming work that's stalled would be ideal to tell
> claude
> > to do,
> > but I'm unsure the project's stance on using claude to move code, and git
> > log
> > 5 different trees to get the original author(s) of the code and make
> > trivial compile
> > tweaks.
>
> The critical thing we don't want is such tools making changes to the
> contents of source files.
>
> Automating the moving around of files is a non-issue.
>
> The use of AI for writing commit messages is arguably in scope of QEMU's
> AI policy given that is part of "the contribution", but it is less serious
> there, since commit messages don't have a copyright implication on what we
> host & distribute.
>
> More important is that the commit messages are accurate and well written.
> LLMs have a tendancy to be overly verbose about irrelevant stuff, and of
> course the well known danger of hallucinating nonsense. IME that makes it
> challenging to benefit from an LLM, due to review & re-writing overheads
> you then incurr to validate and fix their output.
>

Yea, the commit messages llm would generate is 'do function X' and I'd then
fill it in from there, changing everything except X.


> I'd be wary of relying on an AI to extract and report on authorship of
> code. Accuracy is important there since it implies copyright ownership
> associations. Likewise a Signed-off-by tag should be added by humans
> only since it is a statement they are complying with the DCO policy.
>

I'd be verifying everything done. Verification is relatively easy,
extraction is
the hard part. And the range of people it could be is tiny, so I'd know if
it
was making stuff up, or had gone off the rails...  And I'd have it add
something
like 'Supposed-author: ' that I'd change once I verified it. That's ugly
grunt work,
but ugly grunt work I can do in an hour or two rather than the dozens of
hours
it usually takes me to do the extraction...

Warner

Warner Losh <imp@bsdimp.com> writes:

(Cc sniping Paolo/Peter/Markus for AI discussion)

> On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>  We should reflect the current status so users don't have unrealistic
>  expectations of how quickly things can get reviewed and merged.
>
>  Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> Reviewed-by: Warner Losh <imp@bsdimp.com>
>  
>  ---
>
>  [AJB] I realise this is a slightly provocative patch but given how
>  widely used *-user is downstream we should be clear about the current
>  state and hopefully encourage those who rely on it to step-up.
>
> For the bsd-user case this is likely correct. We run hot and cold about being
> proactive at fixing things, and we've been somewhat cold for a while now.
>
> Part of the problem is that this submission process is very very heavyweight
> compared to other projects I contribute to. Not sure what to do about that since
> there's a reluctance to move away from it. Or alternatively, I'm somehow making
> it too hard.

We have discussed in the past allowing maintainers to directly submit
their PRs via GitLab which would be beneficial from a testing point of
view. To move this forward someone needs to propose the changes to our
policy documents so it can be discussed and merged.

However we still expect patches to go onto the mailing list for
review. The greybeards (like myself ;-) are very wedded to the inline
email workflow but if we could keep that interface while making use of
the GitLab UI for those that grew up knowing only the web maybe we could
make the project more friendly to new contributors.

I'd be interested in knowing where the pain points are for you because
modern tools like b4 make some of the grind (collecting tags and
applying patches from ML) a lot easier.

Usually the most difficult thing is getting email setup so you can
git-send-email or git-publish.

> A lot of the upstreaming work that's stalled would be ideal to tell claude to do,
> but I'm unsure the project's stance on using claude to move code, and git log
> 5 different trees to get the original author(s) of the code and make trivial compile
> tweaks.

There was some discussion at the maintainers summit about relaxing the
rules on AI submission for "mechanical" changes but it ran into the
weeds without any firm conclusion. We could certainly revisit it.

I think the concern about potential license pollution is a valid one but
this is more of a concern for "novel" changes made by AI. I've been more
relaxed on my personal FLOSS projects where I have allowed AI
contributions but made it clear that the submitter is expected to
understand whats going on. But being personal projects they are less
likely to be spammed to death by AI slop PRs which seems to be a growing
problem in the wider ecosystem.

>
> Warner 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

On Fri, Jan 23, 2026 at 9:15 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> Warner Losh <imp@bsdimp.com> writes:
>
> (Cc sniping Paolo/Peter/Markus for AI discussion)
>
> > On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> >  We should reflect the current status so users don't have unrealistic
> >  expectations of how quickly things can get reviewed and merged.
> >
> >  Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >
> > Reviewed-by: Warner Losh <imp@bsdimp.com>
> >
> >  ---
> >
> >  [AJB] I realise this is a slightly provocative patch but given how
> >  widely used *-user is downstream we should be clear about the current
> >  state and hopefully encourage those who rely on it to step-up.
> >
> > For the bsd-user case this is likely correct. We run hot and cold about
> being
> > proactive at fixing things, and we've been somewhat cold for a while now.
> >
> > Part of the problem is that this submission process is very very
> heavyweight
> > compared to other projects I contribute to. Not sure what to do about
> that since
> > there's a reluctance to move away from it. Or alternatively, I'm somehow
> making
> > it too hard.
>
> We have discussed in the past allowing maintainers to directly submit
> their PRs via GitLab which would be beneficial from a testing point of
> view. To move this forward someone needs to propose the changes to our
> policy documents so it can be discussed and merged.
>
> However we still expect patches to go onto the mailing list for
> review. The greybeards (like myself ;-) are very wedded to the inline
> email workflow but if we could keep that interface while making use of
> the GitLab UI for those that grew up knowing only the web maybe we could
> make the project more friendly to new contributors.
>
> I'd be interested in knowing where the pain points are for you because
> modern tools like b4 make some of the grind (collecting tags and
> applying patches from ML) a lot easier.
>

I've tried setting up b4 before. I'll have to try again.


> Usually the most difficult thing is getting email setup so you can
> git-send-email or git-publish.
>

The most difficult part for me is 'where the heck did google hide the
password
junk today' so I can turn on a password, do the submission, then kill the
password.
I really wish I could do OTP sometimes.


> > A lot of the upstreaming work that's stalled would be ideal to tell
> claude to do,
> > but I'm unsure the project's stance on using claude to move code, and
> git log
> > 5 different trees to get the original author(s) of the code and make
> trivial compile
> > tweaks.
>
> There was some discussion at the maintainers summit about relaxing the
> rules on AI submission for "mechanical" changes but it ran into the
> weeds without any firm conclusion. We could certainly revisit it.
>

Yea, it's not even mechanical changes. It's copying the work from one tree
to another
after that forked tree has been merged to the latest upstream... There's no
creativity
here at all. I'd be happy just having to write the commit messages... the
hard part is
the datamining to see who wrote things, and splitting out out function by
function
with dependencies for easy review...


> I think the concern about potential license pollution is a valid one but
> this is more of a concern for "novel" changes made by AI. I've been more
> relaxed on my personal FLOSS projects where I have allowed AI
> contributions but made it clear that the submitter is expected to
> understand whats going on. But being personal projects they are less
> likely to be spammed to death by AI slop PRs which seems to be a growing
> problem in the wider ecosystem.
>

Yea. we have a github pull request open, and we have problems from time to
time,
but have been swift to close ai chatbots and other slop we get.

Warner


> >
> > Warner
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>