On 9/29/25 11:35, Kevin Wolf wrote:
It's mentioned earlier, since the responsibility is not limited to
exceptions: "To satisfy the DCO, the patch contributor has to fully
understand the copyright and license status of content they are contributing
to QEMU". I find this sentence to be already a bit heavy, and would prefer
not to make it longer.
Isn't the whole paragraph meant to say that exceptions don't make any of
earlier mentioned requirements go away? So I don't think it would be
redundant in this context, even though of course it would repeat the
requirement just to tell more specifically what it's referring to.
Even though this section is specifically about generated content
exceptions, requirements are not limited to the DCO. Of the other
practices in the file, "where an automated manipulation is performed
on code, however, this should be declared in the commit message" is
an important one in this context. The fourth and more controversial
patch in the RFC included text about providing the prompt and, while
it is premature to have it now, I can imagine this paragraph becoming
a bullet list:
----
Exceptions do not remove the need for authors to comply with all other
requirements for contribution. In particular:
- the "Signed-off-by" label in a patch submission is a statement
that the author takes responsibility for the entire contents of
the patch, including any parts that were generated or assisted by AI
tools or other tools.
- it is highly encouraged to provide background information such as the
prompts that were used, and to not mix AI- and human-written code in the
same commit, as much as possible.
---
Also, for lack of a better place, this sentence about requirements could
even extend to those spelled out by submitting-a-patch.rst. For example,
"use the QEMU coding style", "split up long patches", "don't include
irrelevant changes", "write a meaningful commit message" all serve as
indicators that contributors have properly reviewed and understood any
generated output.
I like the idea that the concerns are split between the exception process
(assessing risk in general) and regular review (assessing code quality of
specific contributions).
Either way, I agree that there is room for clarifying the policy even further.
Thanks,
Paolo
If you don't want to say "copyright or license status" here, referring
to "DCO requirements" would have the same effect (because we do have
the explanation you quoted).
Kevin
