On Mon, 20 Jul 2026 at 08:22, Peter Maydell <[email protected]> wrote: > Reading this comment prompts me to check with you whether you have > read our AI contribution policy, which at present is essentially > a "no AI generated code or text in contributions" policy: > https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-generated-content
Thanks Peter, and fair question -- the answer is yes, AI tooling was used in producing this series, so under the current policy I should not have sent it in this form. I apologise for that, and I appreciate you flagging it directly rather than just dropping the patches. To be transparent about what that means for these patches: this work comes out of a project that runs macOS guests on QEMU/KVM, and I use an AI coding assistant in that project. The comment you quoted is a good example -- it's essentially the assistant's working notes shipped verbatim, which is exactly the kind of thing that shouldn't be in an upstream submission (and, as you say, the development-history narrative doesn't belong there regardless of how it was written). What is *not* AI-derived is the hardware ground truth: the USB descriptors, HID report descriptors and endpoint topology are captured byte-for-byte from real Apple peripherals, and the design decisions (which device to emulate, why Mighty Mouse rather than Magic Trackpad, how it binds in macOS) were mine. But I recognise that doesn't resolve the DCO clause (b) concern about the generated code and text itself, and I don't want to hand-wave that. So I'll withdraw this series for now rather than ask you to review it under a cloud. If I reimplement the device code and comments myself, from the captured hardware descriptors as the spec, would a resubmission be welcome -- or would you rather this category of contribution wait until the AI policy itself is revisited? Not looking to litigate the policy -- just want to be straight about provenance and do the right thing here. Thanks again. -- Matthew
