Hi David, Thanks for sharing this. We will try this at some point how this works. Especially regarding bugs reported closer to a supported Qt version, I see this as being even more fruitful. it may help us identify bugs that should remain open.
Br Jouni Äijälä Senior Manager, R&D ________________________________ From: David Faure Sent: Monday, November 02, 2026 16.46 To: [email protected] Subject: Re: [Development] Re-testing old bug reports before possibly closing them Hi everyone, [Sorry for the new thread, I only resubscribed to the list now] While I appreciate that Jira has a ton of old bugs and that some cleanup is good, I would like to suggest an improvement to the way it's been done. In this day and age, in most cases we do NOT need to delegate to the bug reporter the task of re-testing the bug to indicate if it's still relevant, or if it's been fixed meanwhile. AI can do this for us, especially for Qt issues, it being a library rather than an end-user program (which is doable too, but a bit more complex to set up). I have written the attached skill, which allows me to ask an agent (Claude Opus 5.5 in my case) to verify a set of QTBUG issues, writing a testcase if there isn't one (e.g. based on prose from the bug reporter), to determine if the bug is still reproducible. The skill has two modes: - in manual mode it will only write local files (testcase, report). Use this first, to find out if it's working to your liking. - in auto mode, it will also update the Jira issue (reopen if necessary, update affects version and/or fix version, attach the testcase, close as fixed if that's the case, and add a comment about what was done and why). Install it by copying the two attached files to a new directory ~/.claude/skills/qt-bug-triage/ (or similar if you don't use claude). I recommend saving also a memory or global CLAUDE.md that tells it where your Qt source dirs (and their respective build dirs) are, on your machine. The main benefit of this skill (compared to just pasting a jira URL to your claude) is that it can parallelize the work of looking at many many issues at the same time, distributing the work to subagents, and saving all the details of what it found out in local files. You can then go through the local files at your own pace, i.e. faster than if you have to wait for the AI for every bug. You might argue that it's not as good as having a real human with a real brain doing this. But 1) it's debatable -- I've had *great* results from doing this 2) in any case it's certainly much better for everyone than just closing without any attempt at reproducing the bug. It's better for the reviewer (who currently feels like this report is being rejected just because nobody had time to look at it), it's better for the Qt project (because actual defects are being addressed rather than swept under the rug). PS: I wrote a similar skill for reviewing all MRs brought to my attention, if someone's interested... -- David Faure | [email protected] | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - Trusted Software Excellence Confidential
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
