Il lun 21 set 2026, 13:11 Daniel P. Berrangé <[email protected]> ha
scritto:
> > > +### No automated posting
> > > +
> > > +Agents **must not** use any API, CLI, or web UI automation to:
> > > +
> > > +- Interact on the QEMU mailing lists
> > > +- Create, edit, or close **issues ("work items")**
> > > +- Post **comments** on merge requests, issues or commits
> > > +- Open or update **merge requests (MRs)**. QEMU does not use merge
> requests anyway.
> > > +
> >
> > Are we considering project agents (such as the stsquad-bot) exempt from
> > this policy? I'm not sure what a normal agent can do via the API as it
> > wouldn't have the project level access the stsquad-bot needs.
>
> At least a user's agent can likely bulk file work items without elevated
> access privs, as we've seen by the several slop-bombs we've had.
>
> I'd add a footnote for that along the lines of:
>
> 'Official project agents whose code is maintained under
> gitlab.com/qemu-project
> may be exempted from one or more of these rules, at the discretion of
> the QEMU
> project maintainer(s)'
>
Sure.
> > +### No AI-written text must reach maintainers
> > > +
> > > +These rules apply when publishing AI-assisted work to GitLab or the
> mailing list:
> > > +
> > > +- **AI-written cover letters and commit messages are banned**. These
> are
> > > + easy to recognize and waste reviewers' time.
> > > +- **AI-generated responses to reviewer comments are banned**. This
> undermines
> > > + the human-to-human interaction fundamental to code review.
> > > +- **AI-written issue ("work item") descriptions or comments are
> banned**. These
> > > + are verbose and waste triagers' time.
> > > + - An exception is made for issues for defects detected by automated
> or
> > > + semi-automated tooling, including fuzzers and LLM-assisted defect
> > > + detection. Such issues must be reviewed by a human before
> creation,
> > > + must be created by a human and communication with maintainers must
> > > + be done by a human, but including the verbatim tool output in the
> > > + issue description is explicitly allowed.
>
> I kind of want to eliminate this exception. IMHO from the bugs we're
> getting, I think human's are often putting very little effort into
> reviewing the tools output, such that it is largely a box ticking
> exercise to claim they've reviewed it.
>
> If we removed the exception, and required humans to write up the
> finding of the fuzzer/detect detection in human language, that
> may do a better job of getting people to engage in more critical
> thinking rather than rubber stamping the tool output.
>
> It would limit the ability of people bulk file 50+ tickets in a day.
>
I think that's the problem, namely not realizing there's someone on the
other side.
LLM write-ups are essentially the same as patents, they look like English
but they're not; and the verbosity of the write-ups is sometimes a curse
and sometimes a blessing. There is a tension between having a simple
description of the issue and an unopinionated one. The fix is not always
trivially obvious, and sometimes the "executive summary" from the LLM
points in the wrong direction—I have no expectation that human reporters
will be any better at not misleading me.
In fact I'd rather like us to introduce an explicit rule that a person/
> tool must not file more than about 5 tickets in a single day, without
> prior approval from maintainers, so we don't get bombarded at such a
> high rate.
>
Sure, that's a good idea. Even 5 per month...
Paolo
>
> With regards,
> Daniel
> --
> |: https://berrange.com ~~ https://hachyderm.io/@berrange :|
> |: https://libvirt.org ~~ https://entangle-photo.org :|
> |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
>
>
