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
Just to follow up....
On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote:
>
>
> 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...
>
So, claude looks likeit's doing a passing fair job at this work. I plan on
submitting
a patch series for one of the minor files in the coming weeks (depending on
how much time I can find to work on it). Any guidance you can give me up
front?
Before I submit, I plan on auditing every single change to make sure claude
didn't introduce anything that's not in bsd-user's blitz branch. Make sure
the authors
are correct to the same level that I've been doing so far. And make sure
I've rewritten
all the commit messages.
One question I have, should include these lines
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
it is adding to the commit messages or not? Claude generated this as a
series of
commits from the blitz branch to the master branch, but didn't actually
generate
any new code or fix any bugs. I'm happy to include them if you want, but
also
am weary about setting of a knee-jerk reaction that would be unhelpful since
it's responding to the 'slop' worries and not the merits of the current
work.
Comments?
Warner
On Mon, Feb 02, 2026 at 02:57:57PM -0700, Warner Losh wrote: > Just to follow up.... > > On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote: > > > > > > > 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... > > > > So, claude looks likeit's doing a passing fair job at this work. I plan on > submitting > a patch series for one of the minor files in the coming weeks (depending on > how much time I can find to work on it). Any guidance you can give me up > front? > > Before I submit, I plan on auditing every single change to make sure claude > didn't introduce anything that's not in bsd-user's blitz branch. Make sure > the authors > are correct to the same level that I've been doing so far. And make sure > I've rewritten > all the commit messages. > > One question I have, should include these lines > 🤖 Generated with [Claude Code](https://claude.com/claude-code) > Co-Authored-By: Claude <noreply@anthropic.com> Commit message tags like this are considered to be referring to the code in the commit body, so that would be potentially misleading. Personally, I also don't like the concept of providing free advertizing for commercial tools in commit messages. If you've exclusively used it for commit metadata, then IMHO it would be sufficient to just mention this in the cover letter description, and explicitly say it had no part in writing the code, etc. 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 :|
Daniel P. Berrangé <berrange@redhat.com> writes: > On Mon, Feb 02, 2026 at 02:57:57PM -0700, Warner Losh wrote: [...] >> One question I have, should include these lines >> 🤖 Generated with [Claude Code](https://claude.com/claude-code) >> Co-Authored-By: Claude <noreply@anthropic.com> > > Commit message tags like this are considered to be referring to the > code in the commit body, so that would be potentially misleading. > > Personally, I also don't like the concept of providing free advertizing > for commercial tools in commit messages. > > If you've exclusively used it for commit metadata, then IMHO it would > be sufficient to just mention this in the cover letter description, > and explicitly say it had no part in writing the code, etc. +1
On Mon, Feb 2, 2026 at 2:57 PM Warner Losh <imp@bsdimp.com> wrote: > Just to follow up.... > > On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote: > >> >> >> 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... >> > > So, claude looks likeit's doing a passing fair job at this work. I plan on > submitting > a patch series for one of the minor files in the coming weeks (depending on > how much time I can find to work on it). Any guidance you can give me up > front? > > Before I submit, I plan on auditing every single change to make sure claude > didn't introduce anything that's not in bsd-user's blitz branch. Make sure > the authors > are correct to the same level that I've been doing so far. And make sure > I've rewritten > all the commit messages. > > One question I have, should include these lines > 🤖 Generated with [Claude Code](https://claude.com/claude-code) > Co-Authored-By: Claude <noreply@anthropic.com> > it is adding to the commit messages or not? Claude generated this as a > series of > commits from the blitz branch to the master branch, but didn't actually > generate > any new code or fix any bugs. I'm happy to include them if you want, but > also > am weary about setting of a knee-jerk reaction that would be unhelpful > since > it's responding to the 'slop' worries and not the merits of the current > work. > > Comments? > To not clutter up the mailing list, here's the changes. They are identical to what's in the qemu-bsd-user blitz branch. I've not curated the commit messages yet (they are what claude produced, but there's no copyright issues with commit messages), but plan on doing so since glancing over them right now I do see a few minor issues that need to be tweaked. https://github.com/bsdimp/qemu/tree/bsd-user-claude git diff master..bsd-user-claude --stat bsd-user/bsd-misc.c | 222 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ bsd-user/bsd-misc.h | 386 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ bsd-user/freebsd/os-syscall.c | 57 ++++++++++++++++++++++++++ bsd-user/meson.build | 1 + bsd-user/qemu-bsd.h | 15 +++++++ bsd-user/syscall_defs.h | 67 +++++++++++++++++++++++++++++++ common-user/safe-syscall.S | 2 +- meson.build | 20 ++++----- 8 files changed, 759 insertions(+), 11 deletions(-) The last two are cherry-picks of something I wrote myself. The meson.build is because inotify is now in libc, and I don't know how to express it. so I figured if I did it wrong, somebody would help :). Thanks in advance for any feedback you can provide. Warner
On Mon, Feb 02, 2026 at 05:49:44PM -0700, Warner Losh wrote: > On Mon, Feb 2, 2026 at 2:57 PM Warner Losh <imp@bsdimp.com> wrote: > > > Just to follow up.... > > > > On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote: > > So, claude looks likeit's doing a passing fair job at this work. I plan on > > submitting > > a patch series for one of the minor files in the coming weeks (depending on > > how much time I can find to work on it). Any guidance you can give me up > > front? > > > > Before I submit, I plan on auditing every single change to make sure claude > > didn't introduce anything that's not in bsd-user's blitz branch. Make sure > > the authors > > are correct to the same level that I've been doing so far. And make sure > > I've rewritten > > all the commit messages. > > > > One question I have, should include these lines > > 🤖 Generated with [Claude Code](https://claude.com/claude-code) > > Co-Authored-By: Claude <noreply@anthropic.com> > > it is adding to the commit messages or not? Claude generated this as a > > series of > > commits from the blitz branch to the master branch, but didn't actually > > generate > > any new code or fix any bugs. I'm happy to include them if you want, but > > also > > am weary about setting of a knee-jerk reaction that would be unhelpful > > since > > it's responding to the 'slop' worries and not the merits of the current > > work. > > > > Comments? > > > > To not clutter up the mailing list, here's the changes. They are identical > to what's in the qemu-bsd-user blitz branch. I've not curated the commit > messages yet (they are what claude produced, but there's no copyright > issues with commit messages), but plan on doing so since glancing over them > right now I do see a few minor issues that need to be tweaked. snip > Thanks in advance for any feedback you can provide. I glanced at the commit messages, and they look like that have avoided the usual AI trap of being insanely verbose. They tell the "what" of the code changes, but not so much the "why", which is common with AI since it has no such insight. That's not a problem per-se. The 'why' is optional for any commit. It is applicable if there was something notable about the choices made in the implementation that the author wants to call out to reviewers. If the 'Generated-with/Co-authored-by' bits are removed, I think the commit messages at least are fine to submit, if you consider them accurate. I'll assume all the other usual things are checked, eg that code compiles & tests pass at each commit in the series, checkpatch.pl is clean or any failures are jusifiably ignored as non-applicable/ false positives, etc 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 :|
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 >
On Fri, Jan 23, 2026 at 03:09:24PM -0700, Warner Losh wrote: > > 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. I'll be happy to hear of any parts of the configuration process that weren't obvious. > > 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. You can use the web submission endpoint with b4 submit. -K
© 2016 - 2026 Red Hat, Inc.