Re: [PATCH v2] docs/devel: relax policy on AI-generated contributions

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Jun 05, 2026 at 10:17:16AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 04, 2026 at 12:37:58PM +0200, Paolo Bonzini wrote:
> > Il mer 3 giu 2026, 19:54 Daniel P. Berrangé <berrange@redhat.com> ha
> > scritto:
> > 
> > > The AI policy should just
> > > make a point that we expect to be communicating with people not
> > > bots pretending to be people.
> > >
> > 
> > Yes, it's better to have that stated clearly.
> > 
> > > True but we also need a rule. The spirit is better explained elsewhere
> > > > (and also, building consensus on spirit vs. a rule are two different
> > > > things).
> > >
> > > Do we have a better elsewhere in this case ?  It is a point specifically
> > > about intent of the AI policy rule.
> > 
> > 
> > The rule in this draft says 20 lines, tests, mechanical changes and docs.
> > The spirit is what is in the commit message, basically to maximize the
> > benefit and limit the possible damage?
> 
> Putting "the spirit" in the commit message is essentially /dev/null to
> anyone reading the policy later.
> 
> > > See my reply to Peter elsewhere in the thread. I agree with your
> > > > concerns for both docs and discretion, but I had specific uses in mind
> > > > that I'd like to allow.
> > > >
> > > > For docs:
> > > > - create tutorials and/or feature documentation based on functional tests
> > >
> > > That doesn't sound too appealing to me. Reverse engineering docs or
> > > tutorials from our functional tests is exactly the kind of thing that feels
> > > likely to result in volumous text of marginal value which will have a large
> > > burden on reviewers.
> > >
> > 
> > At the same time this can be helpful for maintainers themselves? Let's also
> > look at this from the point of view of producing better output, not just
> > from that of being on the receiving end of slop. Especially for docs I have
> > a hard time imagining people sending out whole new "manuals"... The
> > bugfixes rule ironically seems the most dangerous to me from the
> > Dunning-Krueger point of view.
> > 
> > My question is: do we want disclosure for anything is created with the help
> > of LLMs, even if only small parts survive untouched? I think so, because a
> > lot more, even if edited, would still be originally from AI. But then it's
> > important to have rules allowing it and a way to track it.
> 
> IMHO need unconditional disclosure, because the use of the LLM impacts
> the license of the code. QEMU is traditionally expected to be GPLv2+
> licensed for all new code, but there's the train of thought that LLM
> code is public domain.
> If it gets human editting afterwards we can
> consider that the human edits are GPLv2+ licensed, but IMHO we still
> want to know the origins.

Wait that's a big ask.

DOC explicitly does not ask if code might be available anywhere else
under any other license. Just that contributor can contribute under GPL.
If it's public domain then the human can license is under GPL.


> 
> 
> > It would definitely be intended for merge. There's a lot of boilerplate
> > code in the Rust bindings, for example, that is voluminous but *mostly*
> > lacks creativity---the creative part basically can be described by the
> > spec/docs and should already clear the low bar required for originality,
> > even if the code is automatically generated. I included a couple examples
> > in my reply to Peter.
> 
> So we know there are examples which are probably low risk from a license
> POV, but which are massively larger than 20 lines of code. This just
> makes me more uncomfortable with the 20 line rule as the definition of
> the policy - we know that rule is wrong / undesirable from the start and
> needs this exception to make it viable.


So 20 lines or mechanical changes? what is considered mechanical will be
decided by maintainers, contributor should check with them up front.

> 
> 
> > The talk about experimenting with LLMS for larger changes emphasizes
> > > experimentation  and use of PRs in order to trigger the run of tools from
> > > their review pipeline.
> > >
> > > That doesn't explicitly say whether such "experiments" are permissible to
> > > be merged though
> > 
> > 
> > There is a part that mentions "pre-arranged, non-critical, high-quality,
> > well-tested, and well-reviewed code changes that are originally created by
> > an LLM", "to experiment with LLMs to inform future policies".
> > 
> > They mention a private channel where maintainers can discuss whether the
> > PRs pass the standards required of LLM changes. The mention of a higher
> > standard strongly suggests that they intend to accept them, otherwise why
> > would you have people do the work for nothing.
> > 
> > Likewise, they say that for CI runs no disclosure is needed while "if a PR
> > is no longer marked as clearly experimental, at that point disclosure is
> > required". The no-longer-experimental PRs fall under the previous rule, and
> > IMO this sentence also supports my reading that they are intended for
> > merging.
> > 
> > This is what I would like to have in QEMU as well, so that people are able
> > to learn. We need to trust maintainers to understand the spirit---which
> > does mean we need to write it down, though. :)
> 
> I'm mostly concerned with the likelihood of inconsistency across areas
> of QEMU if we leave it upto individual maintainers' discretion. This
> doesn't give non-regular contributors a good impression of what's
> allowed and what's not, across the codebase as a whole IMHO.
> 
> With regards,
> Daniel

Always the case in many other areas :) People are inconsistent.


> -- 
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|