Hi Daniel, Thanks for the review. It will take a while to incorporate everything and I'll wait for more feedback, in the meantime just a couple things I can confirm or add...
On Wed, Jun 3, 2026 at 4:59 PM Daniel P. Berrangé <[email protected]> wrote: > IIUC, by "small bug fixes", what you're actually trying to > express is an acceptance of code that is either > > * unlikely to meet the threshold for copyrightability > * small enough that the consequences of throwing it > away is negligible. Yes, these two. > In retrospect, I wonder if we shouldn't have have "ai-usage.rst" as > a separate doc from the start. While we can hyperlink to sub-titles > via anchors, it would be simpler if we could just point to a doc and > not require scrolling past pages of non-AI text. I can split it, especially since there's basically no shared text with the old one. > > @@ -288,62 +288,108 @@ content generators below. > > Use of AI-generated content > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > +Risks to open source projects include maintainer burnout from an > > +increased number of contributions, as well as the risk to the project > > +from unintentional inclusion of copyrighted material in the LLM's output. > > +In order to mitigate these risks, the QEMU project currently allows > > +using AI/LLM tools to produce patches in a limited set of scenarios: > > If we're opening the door to AI assisted contribution, then IMHO we > need to write about both the social and technical expectations. > > Admittedly that will expand the scope of your proposal here, but > IMHO that's somewhat unavoidable. A significant part of the downsides > of AI-assisted contributions comes from bad social practices, rather > than merely bad technical practices. > > As a general theme, I would like us to emphasize at the start that the > act of collaboration & contribution in QEMU is about the interaction, > trust and relationships between humans, not bots. I agree that it needs to be there somewhere. On the other hand I'm a bit worried about having a treatise that no one will read -- at least with stuff like "writing a commit message" we can point people to it. > If someone wants to use tools (LLM based or not) that's a choice, > but the accountability for actions needs to fall on a real human > and there needs to be transparency whenever automation is used. > > This starts from the commit message. A good commit message (and even > more so a good cover letter) describes the intent / thinking behind > the changes. An LLM doesn't think or have intent in its actions, > ergo a human should be driving the authorship of commit mesages / > cover letters, where a non-trivial explanation is needed. > > As reviewers, if we make use of LLM backed tools to respond, then > we need to be transparent about any feedback that came from a bot > rather than from a human. > > As contributors, if a reviewer gives feedback, the contributors > response should be their own rather than just feeding the email > review into a LLM and cut+pasting the LLMs answer back to the > list. > > The identity use to contribute to QEMU should reflect the human's > identify. As previously clarified, this doesn't need to be a real > name, but we don't want LLM agents being given a psuedonym to > pretend to be a human. I'll try to weave these in either this section or a similar one. > > +**Small bug fixes** > > + These should be limited to 20 lines of code or less, not including > > + tests. You are still expected to :ref:`understand and explain your > > changes > > + <write_a_meaningful_commit_message>` and the rationale behind them. > > I think the "20 lines or less" is not going a good job at expressing > the intent behind this point. I'd like us to emphasize between the > "why" of this point, as that helps contributors & reviewers make a > decision of whether a change is "within the spirit" or the rule of > not. 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). > Docs is an area I'm more wary of from the social expectation side rather > than the technical or legal side. I don't feeel like "pay attention to > the organization and flow" really mitigates to the tendancy to production > of vast reams of convincing sounding slop. Reviewers have no obligation to review. The good thing about slop is that saying no takes about the same effort as the author put into the creation of the change. > IMHO it should not be at the discretion of individual maintainers to > accept large-scale AI authored changes outside these guidelines. To > quote the commit message rationale > > "Therefore, it remains prudent to only permit AI assistance where > the ramifications of copyright violations are at least easy to > revert and unlikely to spread" > > that does not suggest we should leave it to the discretion of maintainers > to override the guidelines. 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 - create function comments (including Rust doctests) based on a high-level, human-written description of the module For maintainer discretion: - updating patches for changes to kernel APIs, before the kernel side is ready for inclusion - creation of parsing code for Rust procedural macros based on code examples and/or a human-written description of the macro - creation of boilerplate code similar to hw/core/hotplug.c I think all of these are potentially compelling and I would like people to be allowed to experiment with them or similar cases. The idea of contacting maintainers beforehand comes from the policy currently under discussion in the Rust project. > > +When AI/LLM tools produce or substantively shape your patch, add an > > "shape your patch" -> "shape the content of the submitted patch" > > as this better excludes the "background" usage mentioned below. > > > +``AI-used-for:`` line before ``Signed-off-by``, as a reminder of your > > +DCO obligations and a guide to reviewers. The text is one or more of > > +``code``, ``tests``, ``docs``, ``research``, possibly followed by an > > +explanation in parentheses: > > > > +.. code-block:: none > > + > > + AI-used-for: tests, docs > > + AI-used-for: code > > + AI-used-for: code (refactoring) > > + AI-used-for: code (prototype) > > + AI-used-for: research > > + > > +``AI-used-for`` should not be included for "background" usage such as > > +autocomplete or obtaining a pre-review of the patch. > > This is an interestng idea that I like much more than Assisted-by, > because it gives more directly useful info to the reviewer, without > turning into free advertizing for commercial vendors. Yes! Thanks Kevin. :) > > +There is no requirement to include your prompts or summarize the > > +conversation in the commit message or cover letter, but you may do so > > +if you think it helps a reviewer judge the result. For example: > > IMHO we should actively discourage the inclusion of prompts > entirely as it is the wrong information to provide. Why? I think it helps especially in the case where we're asking for maintainers to apply their discretion, and for reproducibility. It may not be always applicable, but it can also help. > > +**Helpful prompts** > > + These describe concrete constraints or instructions, making it easy for a > > + reviewer to see how the tool's output was guided: > > + > > + * "move field ``foo`` from ``struct aa`` to ``struct bb``. If a > > + function already has a local variable or parameter of type ``struct > > + bb``, use it instead of accessing ``aa.bb``" > > + > > + * "add an implementation of the trait for ``Mutex<T: MyTrait>``; it > > + takes the lock around the calls and forwards to ``T``" > > These examples prompts are just expressing an aspect that should > already have been described in prose in the commit message. We > don't need to classify them as "ai prompts" in a a commit message, > we just need the author to write a useful commit message. The commit message does not have to contain this information. For example, commit 44a9d1b86c0 does not explain that it implements the ToMigrationState{,Shared} traits for Mutex. The commit message could say something like "The implementation of the traits for types ... were created with AI. The prompt was: "add a simple forwarding implementation of the traits in rust/migration/src/migratable.rs for the array type [T; N] and for the interior mutable types Mutex<T> and BqlRefCell<T>. Note that interior mutable types only need T: ToMigrationState in order to implement ToMigrationStateShared". I agree that this is not a typical part of a commit message. On the other hand we do mention occasionally how a commit was automated, and this falls under that case, sort of? See for example commit 324b2298fea ("docs/system: convert Texinfo documentation to rST", 2020-03-06). > > +QEMU does *not* use ``Assisted-by``, ``Co-authored-by`` or ``Generated-by`` > > +trailers to indicate AI usage. In particular, it is not necessary to > > +specify the exact AI model or tool used to create the commit. > > "does not use" doesn't imply "forbidden". > > IIUC, tools are liable to add these tags without the contributor > even asking for them. If we don't want to be providing free > advertizing IMHO we should explicitly forbid use of these tags > and validate this in checkpatch.pl Ok. Paolo > Also any rules in this respect should be documented earlier in > this file where we outline what tags we use in commit messages, > either instead of, or in addition to, mentioning them under the > AI usage guidelines. > > 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 :| >
