Re: [RFC PATCH 08/10] .agents/skills: add qemu-issue-triage agent skill

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, May 07, 2026 at 11:20:57AM +0200, Philippe Mathieu-Daudé wrote:
> On 7/5/26 10:25, Daniel P. Berrangé wrote:
> > On Tue, May 05, 2026 at 06:01:03PM +0100, Alex Bennée wrote:
> > > While triaging the issue tracker I wondered if this would be a
> > > suitable job for an AI agent. Unfortunately the OSS program doesn't
> > > give any credits to run agents in gitlab. However I do have access to
> > > models from my editor and ECA so I built one and tested it on a few
> > > issues.
> > > 
> > > Obviously this can't apply as is because it probably encodes too much
> > > of my local setup (using pass for API keys) and uses the ECA as my
> > > preferred coding agent. I assume at some point there will be agreement
> > > between all the agents where skill live.
> > > 
> > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > 
> > ..snip..
> > 
> > > diff --git a/.agents/skills/qemu-issue-triage/assets/labels.txt b/.agents/skills/qemu-issue-triage/assets/labels.txt
> > > new file mode 100644
> > > index 00000000000..d329f34183d
> > > --- /dev/null
> > > +++ b/.agents/skills/qemu-issue-triage/assets/labels.txt
> > 
> > Seeing our labels listed like this triggers my urge to "tidy" :-)
> 
> Should we improve MAINTAINERS and store these tags there, then
> generate labels.txt?

Tricky question. IMHO the MAINTAINERS file is not neccessarily
the right granularity for issue labels. 


> > > +Storage                    Block subsystem, Storage devices, etc.
> 
> We should really expand this one.

This has always confused me when we have many "block:" labels too.

Mixing backends and frontends is also an anti-pattern for label
tagging.

I'd think 'block:' for all backend stuff, and  'device:storage'
for all frontend stuff


> > > +block:9p                   The 9p network file system
> > > +block:NVMe
> > 
> > These two are not like the others under 'block:'. 'NVMe' is frontend device,
> > and 9p is a filesystem. I'd assume 'block:' applies to block/*.c
> > 
> > > +block:curl
> > > +block:nbd
> > > +block:nfs                  Issues related to the NFS backend
> > > +block:qcow2
> > > +block:ssh
> > > +block:vmdk
> > 
> > Probably want a "block:core" for stuff not specific to one of the listed
> > backends.

> > > +efi                        EFI firmware related issues
> 
> firmware:efi, ...

Yes, we have many more firmwares in git


> > > +guest: AIX
> > > +guest: BSD                 Guest OS is BSD (NetBSD/FreeBSD/OpenBSD/etc)
> > > +guest: Linux               Guest OS is Linux/Linux-based
> > > +guest: Windows             Microsoft Windows guest
> > > +guest: macOS               Apple macOS / Darwin as  guest OS
> > > +guest: os2
> 
> s/guest/guestos/? (vs hostos)

Yes,

> 
> > > +host: aarch64              Bugs reproducible on AArch64 hosts
> > > +host: arm                  Bugs reproducible on ARM hosts
> > > +host: loongarch64          Bugs reproducible on LoongArch64 hosts.
> > > +host: mips                 Bugs reproducible on MIPS hosts
> > > +host: ppc                  Bugs reproducible on Power hosts
> > > +host: riscv                Bugs reproducible on RISC-V hosts
> > > +host: s390                 Bugs reproducible on s390 hosts
> > > +host: sparc64              Bugs specific to Sparc64 hosts
> > > +host: x86                  Bugs reproducible on x86 hosts

And 'hostarch' for these perhaps


> > > +host:32bit                 These are mostly TCG related bugs where we sometimes struggle with emulating larger guests, especially atomic and address space issues.


> > 
> > More space inconsistency
> > 
> > > +hostos: BSD                FreeBSD, OpenBSD, NetBSD, and derivatives as host OSes
> > > +hostos: Linux              Linux-based host operating systems (Fedora, RHEL/CentOS, Debian, Ubuntu, openSuSE et al)
> > > +hostos: Windows            Microsoft Windows host OS
> > > +hostos: macOS              Apple macOS / Darwin as a host OS
> > > +icount                     issues relating to icount, deterministic execution and record/replay functionality

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|