Em sex., 16 de jan. de 2026 às 10:06, Daniel P. Berrangé
<[email protected]> escreveu:
>
> On Fri, Jan 16, 2026 at 09:50:51AM -0300, Julio Faracco wrote:
> > Em sex., 16 de jan. de 2026 às 02:33, Peter Krempa
> > <[email protected]> escreveu:
> > >
> > > On Thu, Jan 15, 2026 at 23:52:29 -0300, Julio Faracco wrote:
> > > > This commit introduces the VIR_DOMAIN_INPUT_TYPE_MULTITOUCH enum value 
> > > > to
> > > > the virDomainInputType enumeration, laying the groundwork for multitouch
> > > > input device support in libvirt.
> > > >
> > > > The new enum value is added to src/conf/domain_conf.h following the
> > > > existing input types (mouse, tablet, keyboard, passthrough, evdev). This
> > > > establishes the fundamental type definition that will be used throughout
> > > > the codebase to identify and handle multitouch input devices.
> > > >
> > > > This is the first step in implementing support for QEMU's 
> > > > virtio-multitouch
> > > > device, which was introduced in QEMU 8.1.0 and enables emulation of
> > > > multitouch events via the libvirt API.
> > > >
> > > > Signed-off-by: Julio Faracco <[email protected]>
> > > > ---
> > > >  src/conf/domain_conf.h | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> > > > index cb35ff06bd..4c448bd010 100644
> > > > --- a/src/conf/domain_conf.h
> > > > +++ b/src/conf/domain_conf.h
> > > > @@ -1554,6 +1554,7 @@ typedef enum {
> > > >      VIR_DOMAIN_INPUT_TYPE_KBD,
> > > >      VIR_DOMAIN_INPUT_TYPE_PASSTHROUGH,
> > > >      VIR_DOMAIN_INPUT_TYPE_EVDEV,
> > > > +    VIR_DOMAIN_INPUT_TYPE_MULTITOUCH,
> > >
> > > We require that the build passes cleanly after each patch. This
> > > obviously won't work with this since you fix up enums later. See
> > > contributor guildelines:
> > >
> > >  https://www.libvirt.org/hacking.html#preparing-patches
> > >
> > >  "If you're going to submit multiple patches, the automated tests must 
> > > pass after each patch, not just after the last one."
> >
> > Oh, I missed that. Thanks for remembering me. It's been a long time
> > since my last contribution.
> >
> > >
> > > Multiple of your commit messages and especially 7/8 also have a strong
> > > LLM vibe. Note that we don't allow AI contributions:
> > >
> > >  https://www.libvirt.org/hacking.html#use-of-ai-content-generators
> > >
> > >  "Current libvirt project policy is to DECLINE any contributions which
> > >  are believed to include or derive from AI generated content. This
> > >  includes ChatGPT, Claude, Copilot, Llama and similar tools."
> > >
> > >
> > > Specifically paragraph:
> > >
> > >   "These additions ensure that multitouch devices are fully integrated
> > >   with libvirt's security, auditing, and validation infrastructure.
> > >   Without these changes, multitouch devices would trigger warnings about
> > >   unhandled enum values or potentially cause security labeling failures.
> > >
> > > strikes as AI. Because it's overly verbose and half of the things that
> > > are mentioned are not even true (e.g. it adds no-op code to the selinux
> > > driver), the other half is trying to justify fix for build failures from
> > > previous patches.
> > >
> >
> > I DO NOT use AI agents to generate code obviously, but I do to improve
> > the quality of the commit message/cover letter.
> > Let me resend the patch to fix the compilation issues and use my own words
> > then.
>
> Using an AI agent to improve commit messages *is* permitted under policy.
>
> Whether written by a human or LLM, the overriding expectation is that
> the commit messages are providing an appropriate level of detail for
> the type of change being made and that they are accurate of course.
>
> Given AI agents tendancy to be ridiculously verbose LLM generated commit
> messages are quite likely to need significant editting to reduce verbosity,
> aside from vetting that it is accurate.
>
> IMHO that suggests LLMs are not especially beneficial for writing commit
> messages, but contributors can make that decision for themselves, as long
> as the result is accurate & appropriately verbose for the change.

What I have tried to say is exactly that: before sending the patches I
just ask LLMs to review the commit messages of my patches and make
improvements.
But yes, it tends to increase the verbosity significantly.

Well, I understood the feedback. Let me fix the patchset and resubmit
using my own words only.
(Perhaps one good adjustment is just using LLMs to fix orthography and typos)

>
> With regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>

Thanks!

--
Julio Faracco

Reply via email to