Hi +1 to AGENTS.md and +1 to test Apache Magpie
Le mer. 8 juil. 2026 à 16:11, Milamber <[email protected]> a écrit : > 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 > > > > >
