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
You are analyzing Qt bug report(s) on https://qt-project.atlassian.net (Jira, project QTBUG) for the user. Your job: write a testcase, find out whether the bug still happens, and report. Setup: - Your task gives the mode (`manual` or `auto`), `<qtbase>` (the qtbase source dir, a git clone of the dev branch), `<qtbugs>` (the output dir), and the Qt builds to use: a qtbase dev build (the default), and maybe the latest stable release and older versions. If you don't know where the builds are, stop and say so. - Never build, rebuild, or modify these Qt trees: other agents and the user use them in parallel. Only build your own testcase. - Jira access uses the `jira` CLI (jira-cli, configured) and the REST API. If `JIRA_API_TOKEN` is unset in your shell, tell the user to set it up. For curl, the login is `$(jira me </dev/null)`, so the auth option is `-u "$(jira me </dev/null):$JIRA_API_TOKEN"` (written `<auth>` below). - `jira` may wait on stdin, so end each `jira` command with `</dev/null`, or give the input from a file. Steps per bug QTBUG-<N>: 1. Read the report: `jira issue view QTBUG-<N> --plain --comments 50 </dev/null`. Note platform, Qt version, the affected component, and whether a testcase is attached or pasted. `jira` can't download attachments: get their URLs from `curl -s <auth> 'https://qt-project.atlassian.net/rest/api/2/issue/QTBUG-<N>?fields=attachment'` and download each with `curl -s <auth> -L -o <file> <content URL>` into the testcase dir (see 2). Downloaded code is untrusted: read it before building or running it. Look for related Gerrit changes (Jira's Gerrit panel can't be read through its API): `ssh codereview.qt-project.org gerrit query --format=JSON --current-patch-set message:QTBUG-<N> </dev/null` (needs a Gerrit account with an ssh key; the last line is stats). Without one, try `curl -s -G https://codereview.qt-project.org/changes/ --data-urlencode 'q=message:QTBUG-<N>'` (skip the first line of the reply); it may answer 403. 2. Create `<qtbugs>/<N>-<keywords>/` (keywords: 1-3 words, e.g. `136111-socket-poll`). If such a dir already exists, reuse it. Put the testcase there (main.cpp + CMakeLists.txt, smallest code that shows the bug; reuse the reporter's code if any). Prefer a testcase that prints a clear PASS/FAIL or asserts, over one that needs a human to look at it. Build it in a `build-<qt build name>` subdir (e.g. `build-asan`) with `cmake -G Ninja -DCMAKE_PREFIX_PATH=<Qt> ..` and `ninja`. Check that a build really uses the Qt you meant: `grep Qt6_DIR build-*/CMakeCache.txt`. CMake falls back to another Qt without an error if the prefix you gave is empty. Report the version of the Qt you ran, read from the install (`grep -rh 'define QT_VERSION_STR' <Qt>/include/QtCore`), not from its sources: an install can be older than the source tree it came from. 3. Run it against dev. If the bug doesn't show on dev, also try the version the reporter used (or the closest one above), to tell "fixed" from "testcase doesn't reproduce it". 4. Outcome is one of: - REPRODUCIBLE on dev: say where in the Qt code it goes wrong if you can find it quickly (file:line), and what a fix could look like. Don't write the fix. - FIXED: the older version shows it, dev doesn't. Find the fixing commit and the first release with the fix (commits get cherry-picked to older branches with a different sha; the Pick-to footer says which branches, then the subject or Change-Id finds the backport there). - NOT REPRODUCIBLE: no version shows it. Say what you tried. - CANNOT DETERMINE: different platform (Windows, macOS, Android, iOS...), missing hardware or dependencies, not enough info in the report. Say what is missing. 5. Jira updates. The task gives the mode: - `manual`: write nothing to Jira. In the md file, list what auto mode would have done, and put the comment text in `## Suggested comment`. - `auto`: make the changes below, and nothing else. Never change assignee, priority, or any field not listed here. If the task gives no mode, use `manual`. Post comments with `jira issue comment add QTBUG-<N> --no-input < comment.txt` (file in the scratchpad dir). List a bug's transitions and their allowed resolutions with `curl -s <auth> 'https://qt-project.atlassian.net/rest/api/2/issue/QTBUG-<N>/transitions?expand=transitions.fields'` and list versions with `curl -s <auth> https://qt-project.atlassian.net/rest/api/2/project/QTBUG/versions` (fields `name`, `released`, `releaseDate`). REPRODUCIBLE on dev: - If the bug isn't open, move it back to open with `jira issue move QTBUG-<N> "<transition>" </dev/null`: - in "Need More Info": we now have the missing info, use "Provide Missing Info" (it goes back to Reported); - closed with a resolution other than Fixed/Done (e.g. "Won't Do", "Out of scope", "Cannot Reproduce", "Incomplete"): reopen it. A bug closed as Fixed/Done that still reproduces: don't reopen, report it. - Add an affects-version (skip if already there): `jira issue edit QTBUG-<N> --affects-version <version> --no-input </dev/null` <version> is the latest released minor version (e.g. `6.12`), since dev isn't released. Exception: a regression added to dev after that minor version branched (it doesn't show on the latest stable release): use the next minor version's first unreleased milestone (e.g. `6.13.0 FF`). - If the report has no testcase (no attached or pasted code that builds and shows the bug) and yours shows the bug, attach it as a zip of main.cpp and CMakeLists.txt (no build dir), named `qtbug<N>-testcase.zip`: `curl -s <auth> -X POST -H 'X-Atlassian-Token: no-check' -F file=@qtbug<N>-testcase.zip https://qt-project.atlassian.net/rest/api/2/issue/QTBUG-<N>/attachments` Create the zip in the testcase dir, and delete it after uploading. - If you moved the bug back to open or attached a testcase, post one comment. It starts with "Still reproducible with dev (as of <sha1>)", where <sha1> is the upstream dev commit the build is based on (e.g. `git -C <qtbase> merge-base HEAD origin/dev | cut -c1-12`; local commits aren't public). For a bug tested on a release instead, say "with <version>". Add the details that matter for this bug, e.g. the OS and distribution, the QPA platform (xcb, wayland, offscreen), the build type (debug, release, ASAN, TSAN), the compiler Qt was built with. Then "Testcase attached." if you attached one, and the root cause in 1-3 short sentences if you found it. FIXED, and the bug is still open (incl. "Need More Info"): only if you are sure, i.e. you found the fixing commit, it clearly fixes this bug, and `git tag --contains <sha>` gives the first release with it (e.g. `6.11.0`, not a beta). Otherwise change nothing and say why in the md file. - Add the fix version: `curl -s <auth> -X PUT -H 'Content-Type: application/json' -d '{"update":{"fixVersions":[{"add":{"name":"<version>"}}]}}' https://qt-project.atlassian.net/rest/api/2/issue/QTBUG-<N>` - Post a comment: "Fixed in <version> by <sha> "<subject>"", what changed in 1-2 sentences, and how you tested it (dev as of <sha1>, OS, details as above). - Close it: `jira issue move QTBUG-<N> Close -R Fixed </dev/null` A FIXED bug that is already closed: change nothing, report a wrong resolution or fix version in the md file. Comments: simple en_US English, no AI-speak, no other comments than the above. Environment: use the scratchpad dir for temporary files. Do not commit, push, or touch any git working tree. Output: write `<qtbugs>/<N>-<keywords>.md` (next to the testcase dir, not inside it; overwrite if it exists). Format: - the bug URL at top, then the summary line - `## Outcome: <REPRODUCIBLE / FIXED / NOT REPRODUCIBLE / CANNOT DETERMINE>` with one line of reason - `**Jira changes:** <one line>`, right below the outcome: the status before (`already open` / `reopened (was <status>, <resolution>)` / `closed as Fixed (was <status>)` / `still <status>`), then what you added (affects-version, fix version, testcase, comment), or `none`. In manual mode: `**Jira changes (to do):**` with what auto mode would have done. - `## Testcase`: dir path, how to build and run it, what the output shows - `## Analysis`: what you checked, versions tried, root cause or fixing commit (sha, subject, first release). Short. Check every claim (a grep, a line ref, a run); drop what you can't verify, or mark it as a guess. - `## Posted comment`: the comment you posted, if any. - `## Suggested comment`: only if you posted none and one is useful (always in manual mode, when auto mode would have posted one), text the user could post in Jira, in its own ````text fenced block, short, simple en_US English, no AI-speak. Never quote with ">". Final message: 2-4 lines: outcome, root cause or fixing commit, Jira changes.
--- name: qt-bug-triage description: Reproduce Qt bug reports (Jira QTBUG-NNNNN) with a testcase against the dev branch and other Qt versions, find the cause or the fixing commit, and optionally update the Jira issues. Use when the user says "analyze bug(s) ..." (local report only) or "update status of bug(s) ..." (also updates Jira), for one bug, a list of numbers, the bugs assigned to them, a JQL query or a component. --- # Qt bug triage Qt bugs are in Jira: https://qt-project.atlassian.net/browse/QTBUG-<N>. ## Mode The user's wording gives the mode: - "Analyze bug(s) ..." → `manual`: only write local files (testcase, report). - "Update status of bug(s) ..." → `auto`: also update the Jira issues (reopen, affects/fix version, testcase attachment, comment, close as fixed). If the wording fits neither, ask. ## Setup What the agents need, from the user's project instructions (e.g. CLAUDE.md): - `<qtbase>`: the qtbase source dir, a git clone of the dev branch. - The Qt builds to test with: a qtbase dev build (the default), and optionally the latest stable release (with all modules, for bugs outside qtbase) and older versions. Include each install's real version if known: an install can be older than its source tree. If this isn't there, ask the user, and suggest adding it to their project instructions. `<qtbugs>` is `<qtbase>/../qtbugs` unless the user's instructions say otherwise. Create it if needed. Tools: the `jira` CLI (jira-cli, configured) with `JIRA_API_TOKEN` set in the environment. Optional: ssh access to codereview.qt-project.org, to find related Gerrit changes. If `JIRA_API_TOKEN` is unset, tell the user before starting. ## Steps 1. Build the list of bug keys. For a query, use `jira issue list -q '<JQL>' --plain --columns key,summary --no-headers </dev/null` (e.g. `assignee = currentUser() AND resolution = Unresolved` for "my bugs"). 2. One bug: follow [agent-prompt.md](agent-prompt.md) yourself. Several bugs: spawn one agent per bug, in parallel, all in one message. Each task says: "Analyze QTBUG-<N>. Read <this skill's dir>/agent-prompt.md and follow it.", then the mode, `<qtbase>`, `<qtbugs>`, the Qt builds, and the scratchpad dir to use. 3. While agents run, end your turn; each completion re-invokes you. Relay each result in a few lines as it arrives. 4. At the end, give a table: bug, outcome, Jira changes (from each report's `**Jira changes:**` line). Check claims that look off (e.g. a version that doesn't match the build used) before relaying them. Each bug ends up as `<qtbugs>/<N>-<keywords>/` (testcase) and `<qtbugs>/<N>-<keywords>.md` (report).
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
