Il mer 3 giu 2026, 19:54 Daniel P. Berrangé <[email protected]> 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? > > 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. > > Can we do this more incrementally and have a more tightly constrained > guide for docs initially and review it again at a later date if we feel it > is worth relaxing further. > Sure. Maybe the same can be done for boilerplate changes like the one I suggest below? > 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. > - create function comments (including Rust doctests) based on a > > high-level, human-written description of the module > > This feels interesting to trial. > > The key difference with function comments is that you don't really have > any of the trouble with document structure & coherence. The API docs should > be comparatively smaller & easier to read & digest and give feedback on > accuracy of. True. > 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. > > Those are largely in direct conflict with the intent behind only allowing > "small bug fixes" Either we accept broad contributions like this as a > project, or we don't - I don't see that as something that is suitable for > per-maintainer discretion. If it will not be intended for merge, then the > policy is irrelevant and people can just experiment out of tree at will. 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. I have no preference for writing English or a programming language, but writing both sucks and LLMs are much better at coding than writing specs (plus, code can be tested). This is exactly the opposite of small bug fixes which are themselves the product of a creative process (debugging) but small enough that, once you've debugged them, there's basically only one way to write them. > The idea of contacting maintainers beforehand comes from the policy > > currently under discussion in the Rust project. > > I presume you're looking at > > https://github.com/rust-lang/rust-forge/pull/1040/changes Yes. What I find interesting there is that their rule that is comparable to your > "small bug fixes" rule, emphasizes it is about allowing "trivial" chances > and specifically references the idea of a threshold for originality / > copyrightability. I find that more satisfying than talking about lines of > code and bug fixes. It's also more abstract though; and doesn't touch on what happens if you stumble on someone else's threshold of originality. We're not lawyers, and our contributors probably have thought even less about these issues. That's why both Rust's policy and this proposal have (different) concrete ways to stay within the spirit. 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. :) Paolo I don't know if the Rust project has specific terminology here, but my > reading of that was that people can agree to collaborate publically on LLM > work, but that does not appear to give individual maintainers permission to > waive the LLM policy rules to merge arbitrary LLM code in the way this QEMU > proposal suggests.
