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 <[email protected]> > > > > ..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 :|
