On Mon, 20 Jul 2026 at 17:51, Matthew Jackson <[email protected]> wrote: > > 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?
I think that if you reimplement the code and comments that would be OK with our AI policy -- as you say the descriptor stuff is basically just data. What I don't know is whether there's anybody interested in reviewing this particular device model: the whole QEMU USB subsystem is currently in the "Orphan" state, and I'm not sure how many people upstream are interested in macos guests. So it's possible that if you do the work to reimplement and submit a human-written version of this functionality that the patches will still struggle to get review. I suspect your applesmc patches are in a similar limbo, so maybe the path forward is if you can find somebody who's interested in reviewing those, see if they'd also be interested in reviewing a reworked equivalent of these apple mouse/kbd devices, and don't do the rework until you're reasonably confident you have a reviewer lined up ? I have cc'd Mohamed Mediouni, who said on IRC that they might be interested in reviewing some of these series. thanks -- PMM
