Daniel P. Berrangé <[email protected]> writes: > 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" :-) > > Don't take anything below to be a complaint / blocker about this patch. > This patch is fine in so much as it faithfully represents the mess we > have created in gitlab. > >> @@ -0,0 +1,133 @@ >> +# SPDX-License-Identifier: GPL-2.0-or-later >> +ACPI Power Management related (ACPI / SMBIOS / HEST / >> GHES) >> +Audio Audio devices; both backend (host audio) and frontend (guest >> audio) > > Mixing frontend and backend is a bad idea in general IMHO. > > I feel like we should also have an explicit label for each backend, for > both audio and every other backend type.
Backend: chardev Backend: audio ? I suspect the block backends are special enough they should stay part of block: - what other backends do we have? > >> +Audit Tooling A group for bugs and issues found via automated >> tooling such as fuzzing, sanitizers or AI >> +Audit Tooling::AI For bugs found with AI assisted tools such as >> Mythos and other similar things >> +Audit Tooling::Fuzzer Issues found via fuzzing. For security >> issues, please consult >> https://www.qemu.org/contribute/security-process/ >> +Audit Tooling::Sanitizer For issues found using sanitizers such as >> asan, lsan and tsan > > Labels with "::" are mutually exculsive, which is possibly not > what we want here ? Should the first thing be 'Audit Tooling::Other' > instead of unqualified ? I've added that, as well as Audit Tooling::Static Analysis for Coverity. > >> +Bite Sized Candidates for first contributions; see also >> https://wiki.qemu.org/Contribute/BiteSizedTasks >> +Build System configure, make, Meson, ninja, gcc, clang, >> ccache, etc. >> +CI Continuous Integration; gitlab, travis, patchew, >> etc. >> +CLI Command Line Interface >> +Chardev Character device backends and related issues > > We should have per-backend labels > >> +Closed::Duplicate There is already another ticket that is about the >> same issue >> +Closed::Fixed The issue was fixed. Yay! >> +Closed::Invalid This issue was not really a problem >> +Closed::NotOurBug This is a bug, but not a bug in QEMU. Please >> report it and/or include a link to the report. >> +Closed::NotReproducible This issue was not reproducible >> +Closed::UnbackedFeature Nobody was willing to work on this feature >> request >> +Closed::WontFix The issue was acknowledged, but the fix would be >> too complex, too expensive, or would introduce other problems. >> +Cryptography >> +Documentation Sphinx documentation, man pages, the wiki, --help >> output, etc. >> +GDB Issues relating to using GDB via the gdbstub >> +GUI Graphical User Interface (gtk, SDL, curses, VNC, spice, ...) >> +GUI::Cocoa Cocoa >> +GUI::DBus DBus >> +GUI::GTK >> +GUI::SDL SDL >> +GUI::SPICE SPICE > > spice is duplicated later Prompt: "find all the issues with the "spice" label and label them with the GUI::SPICE label instead" the result was: general: relabling spice issues (5 steps, 13.5K / 1M) ✅ 1m 26s I have successfully relabeled all GitLab issues in the `qemu-project/qemu` repository by replacing the "spice" label with the "GUI::SPICE" label. ### Summary of Actions: - **Total Issues Updated**: 21 (including both open and closed issues). - **Relabeling**: Removed the `spice` label and applied the `GUI::SPICE` label to each identified issue. - **Verification**: Confirmed that `glab issue list --label spice` now returns no results, while `glab issue list --label "GUI::SPICE"` includes all updated issues. ### Updated Issues: The following 21 issues were updated: `3148`, `3070`, `2860`, `2667`, `2639`, `2561`, `2411`, `2335`, `2282`, `2071`, `1926`, `1829`, `1778`, `1777`, `1553`, `1549`, `1431`, `1426`, `1285`, `681`, `232`. about 0.08p in inference costs. > >> +GUI::VNC > > I'd probably suggest "ui" as the prefix to match the dir / subsystem > name. > > Also probably use ":" instead of "::" as there could be cases where > a bug affects multiple UIs. > >> +Guest Agent Issues related to the qemu-guest-agent binary. >> https://wiki.qemu.org/Features/GuestAgent >> +Hard I think there is 1 bug that is Hard. >> +Launchpad Issues migrated from Launchpad >> +Migration > > Surprised we don't want more categories here > >> +Modules >> +Networking >> +Python Python library issues (./python/) >> +QAPI/QMP QEMU API / QEMU Machine Protocol, HMP and CLI, >> etc. >> +QOM QEMU Object Model >> +Regression >> +Security >> +Semihosting Semihosting calls provide a simple ABI for early >> bring-up of embedded devices and provide a way to output to the >> console and do basic file i/o while being debugged >> +Softfloat QEMU's FPU emulation code (TCG only) >> +Stable::can't fix The bug was reported on a stable branch but the >> fix is too invasive for backporting >> +Stable::obsolete The bug was reported on a stable branch that is >> not maintained anymore >> +Stable::to backport The bug was reported on a stable branch and >> needs to be backported on the next release from the branch >> +Storage Block subsystem, Storage devices, etc. >> +TCG plugins Anything related to the TCG plugins feature > > Perhaps accel:tcg:plugins ? > Plugins currently implies accel:tcg but I'm not sure it is directly accelerator related. Some of the run-loop hooks are TCG agnostic. >> +TestCase The report includes a testcase >> +Tests qtests, iotests, acceptance tests, VM tests, docker tests, >> and more. >> +USB >> +VFIO > > This annoying sorting of all uppercase, then all lowercase is > present in the gitlab UI too > > https://gitlab.com/qemu-project/qemu/-/labels > > We should probalby be universally lowercase, so that sorting is > sensible. > >> +accel: HAX Intel's Hardware Accelerated Execution Manager >> (HAXM) >> +accel: HVF Apple Hypervisor Framework >> +accel: KVM Linux Kernel-based Virtual Machine >> +accel: TCG QEMU Tiny Code Generator >> +accel: WHPX Microsoft Windows Hypervisor Platform (WHPX) >> +accel: Xen Xen Hypervisor > > We're inconsistent in whether we use a space after ":". Here we do, > below we don't. > >> +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. I'll let the block guys fix this up. > >> +bsd-user >> +device: PCI >> +device: TPM Trusted Platform Module (TPM) devices >> +device:graphics Issues relating to display device emulation, or >> rendering in general. See also "GUI". >> +device:input Keyboards, Mice, Touchscreens, HIDs, etc. >> +device:iommu IOMMU and SMMU >> +device:pflash Parallel NOR flashes emulation >> +device:sdmmc SD or (e)MMC cards emulation >> +device:virtio virtio-related issues. >> https://www.linux-kvm.org/page/Virtio >> +device:watchdog > > Here we sometimes have a space after : and sometimes don't > > >> +efi EFI firmware related issues >> +flaky-ci For test cases that are flaky when run under our >> CI >> +gitlab > > So should we be using "CI" or "gitlab" for CI issues :) > > Probably we should have: > > ci:gitlab > ci:flaky > >> +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 >> +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 >> +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 > > Perhaps accel:tcg:icount ? > >> +kind: Not user visible > > What's this for, and why : instead of :: ? No idea - is this the mechanism we use to hide live security issues? > >> +kind::Bug Bug or defect in functionality. >> +kind::Feature Request Feature request or new functionality. >> +kind::Task Research, investigations, and miscellaneous >> issues. >> +libvfio-user >> +linux-user >> +qemu-img > > Should we have a "tools:qemu-img", and "tools:...." for everything > else too ? > >> +spice > > Redundant with 'GUI::SPICE" > >> +sysadmin > > Any idea what this is supposed to refer to ? there is one issue where CI runs fail on some runners and not others. I added some flavour text. > >> +target: alpha DEC Alpha [alpha] >> +target: arm Arm AArch32 or AArch64 [arm, aarch64] >> +target: avr Atmel AVR [avr] >> +target: hexagon Qualcomm Hexagon [hexagon] >> +target: hppa Hewlett-Packard Precision Architecture; HP/HP, PA-RISC >> [hppa] >> +target: i386 Intel/AMD x86 [i386, x86_64] >> +target: loongarch loongarch64 target architecture >> +target: m68k Motorola 68000 [m68k] >> +target: microblaze Xilinx MicroBlaze [microblaze, microblazeel] >> +target: mips MIPS [mips, mipsel, mips64, mips64el] >> +target: nios2 Altera Nios II [nios2] >> +target: openrisc OpenRISC [or1k] >> +target: ppc IBM Power Architecture, PowerPC [ppc, ppc64, >> ppc64le] >> +target: riscv RISC-V [riscv32, riscv64] >> +target: rx Renesas RX [rx] >> +target: s390x IBM Z, SystemZ, zSeries [s390x] >> +target: sh4 Renesas SuperH [sh4, sh4eb] >> +target: sparc Sun Microsystems SPARC [sparc, sparc64] >> +target: tricore Infineon TriCore [tricore] >> +target: xtensa Tensilica Xtensa [xtensa, xtensaeb] >> +workflow::Confirmed Bugs that have been confirmed and reproduced. >> +workflow::In Progress Someone is working on this issue. >> +workflow::Needs Info Issue has insufficient information to verify. >> +workflow::Patch available A patch is available >> +workflow::Triaged Issue has been triaged and given a topic label. > > > With regards, > Daniel -- Alex Bennée Virtualisation Tech Lead @ Linaro
