Hi Vladimir, You're right that PRs aren't our real issue, and you're right that a dashboard doesn't resolve anything, it's a map/report, not the work. So let me focus on the issue backlog, which is the real problem.
Magpie is not just dashboards. Most of its skills *act* with a human confirming every step, they don't just chart. * PRs: triage classifies the queue and drafts the contributor feedback, code-review posts inline review comments, quick-merge surfaces the trivial ones ready to merge, and mentor drafts a teaching reply for a first-time contributor. * Issues: triage proposes a disposition, reassess reads an old report and re-runs the reporter's own code against master, reproducer extracts and executes the example, deduplicate merges two reports, and fix-workflow drafts the actual patch plus its test. The dashboards are only the map on top; the skills are the work and they are what lighten the load on contributors and maintainers. 1) "Where are the skills? They're not in the PR." Correct, and on purpose. Only the small magpie-setup bootstrap + our config are committed. The 68 skills are NOT vendored into git, they live in a gitignore snapshot (.apache-magpie/) that /magpie-setup skill fetches on demand. That is precisely the minimal footprint: we don't drop megabytes of framework into JMeter's history. Each contributor runs /magpie-setup once and the skills appear locally (because gitignore). And each contributor can choose to call a skill from Magpie, or not use Magpie at all. It's an opt-in. 2) ".apache-magpie-overrides will go out of date, what's the plan?" a/ Those files are small and slow-moving (repo name, label names, our CI-check names), they change rarely. b/ Magpie has a reconciliation meta-skill: on /magpie-setup upgrade, local overrides are automatically reconciled against upstream changes and any drift is surfaced for review (and setup-upstream-fix pushes our own improvements back). So maintenance is "run upgrade periodically", not "hand-maintain forever". 3) The issue backlog (the main issue) I agree completely: 800+ issues, and what's needed is a local resolutions database with per-issue analysis, not a chart. That is exactly what issue-reassess produces (one verdict.json per issue), and issue-reassess-stats aggregates them. Then I actually ran the campaign you described: a real reassess over 134 issues (the entire "need info" + "PatchAvailable" buckets), read-only, nothing posted: The results : https://gistpreview.github.io/?2a597279b3e1b2dfa611570b86ae7dc8 The outcome is like your pgjdbc experience, itemised with per-issue evidence: - 76 of 134 (57%) are closeable right now: * 32 stale, 12 invalid, 10 to reclassify as questions, 9 already-fixed (each with a FixedInTrunk label + commit), 8 obsolete, 5 duplicates - 58 are genuine work to keep: * 32 fixes, 11 with a patch already in the thread, 1 security - 26 carry runnable code and are flagged as issue-reproducer candidates The full verdict database (JSON + CSV: number, class, confidence, evidence, action) is kept locally. Note #6394 is one you commented on last November: a clean issue-reproducer target (a self-contained SaveService.loadTree() call that can be re-run against master). That is the "local database + analysis" you described, the skill builds it for you, and for issues with runnable code it re-runs the reporter's example against master. And that is where Magpie helps the contributor/committer/PMC about the JMeter's real problem, the issues. I would like recall that we have another issue: JMeter has very few *active* committers or PMC members left to work the issue tracker, and that is exactly what I want to change with Magpie (not to replace anyone), but to add the *option*/*possibility* of these skills so the few active hands go further. Using Magpie is optional, it has to be activated by each contributor, and its footprint in JMeter is small (IMHO). On the points that you have some doubts: - CVE: agreed it's rare, the security issue is rare, not a daily issues. But #6714 is open right now, and the reassess pass flagged it without anyone asking. And with the GLASSWING project coming (as you know), we will probably receive some CVEs's issues to handle (I hope not a lot!). - Release: I won't claim Magpie makes a release trivial. I'd rather test the release skills on the actual 5.6.x / 6.0 cut and report back, in worst case they draft the [VOTE]/[RESULT]/[ANNOUNCE] boilerplate and tally votes against the roster, which is real time saved even if the hard parts stay manual. I've been the release manager for over 10 years, so of course I already know I don't need Magpie / skill for it. What I want to find out is whether Magpie makes it easier and simpler. I think of the release-management skills like a car's driver-assistance features: you can absolutely drive without them, but using them makes the drive simpler and helps. Same for the publishing/announce side, I can do it myself. You can have some doubts, but we can testing to see if it's magpie can help, and if it's not, so we can rollback / remove magpie. Next steps: The vote / validation to include Apache Magpie in JMeter (the PR #1 on my personal fork), I hope to have your validation, because you are an active PMC (the most active). I will try to be more active also (specially for glasswing, triage and release) @Antonio @PMC your comments or validation are welcome. A test campaign has already run, so the PMC can judge on results. With no objection, I can share the 76 issues which can be closet for validation in [email protected] (by committer and PMC), if ok, we can close it. After (If ok with Apache Magpie integration), I can extend over the rest of the backlog, and hope that will provide the same result as the test campaign. (For the AGENTS.md, follow the PR #2 on my personal fork) (For Microsoft APM, perhaps prepare a PR also? it's complementary to Magpie (which it's more focused set of ASF committer/PMC/release/security workflows)) Milamber Le mar. 7 juil. 2026 à 22:38, Vladimir Sitnikov <[email protected]> a écrit : > >Only pr-management, issue and security are wired so far > > Please clarify where the skills are as they are definitely not a part of > the PR. > > >https://github.com/milamberspace/jmeter/pull/1/ > > So far it looks like "magpie sources" rather than skills useful for jmeter. > There are files under .apache-magpie-overrides that will go out of date > quite soon. I wonder what is the plan to keep them up to date. > > > Frankly, I would approach the true problems we have. > > PRs are not a problem at all. > Issue triage is a bit of an issue. > However, we have ~800+ issues, so if somebody goes through them, they > would probably want to create a local database with resolutions, and the > analysis. > > I did pass over 400 issues in pgjdbc/pgjdbc, and the outcome was like 100 > closed as "already fixed", some closed as "invalid", and many in "to be > analyzed further". > I expect something like that in JMeter, and I think "pr dashboard" and > "issue dashboard" won't really help. > > CVE automation? Well, I don't remember last time we handled a CVE, so it > is definitely not a top priority. > Release automation? Well, we do need to release 5.6.x and 6.0. Does that > require Magpie? I doubt so. Will Magpie simplify the release? I doubt so. > > Vladimir > >
