Hi Jouni, Thanks for your reply. I disagree that it should only be applied to recent bugs.
To pick a few random examples: - you closed https://qt-project.atlassian.net/browse/QTBUG-46070 because it was 11 years old and tagged Qt 5.4, I determined it was still applicable in dev and reopened it - you closed https://qt-project.atlassian.net/browse/QTBUG-49415 because it was tagged Qt 5.5, I determined it was still applicable in dev, reopened it, and actually fixed it. - you closed https://qt-project.atlassian.net/browse/QTBUG-59173 (QStandardItem::setAutoTristate(), more of a missing feature than a bug) because it was tagged Qt 5.6, I reopened it and actually implemented it. Clearly launching the AI on old bugs to see if they can still be reproduced has great value, there's nothing different about the fact that a bug was opened for Qt 5 or for Qt 6, it only means that we didn't have time to look at it before, nothing else. David. On Wednesday 4 November 2026 11:44 Jouni Äijälä wrote: > 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 > -- 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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
