Hi, Thanks for the quick feedback.
I put together a one-page overview that answers most of this with live JMeter data (prepared with Claude); the rest of this mail is the short version with some of my comments. Overview: https://gistpreview.github.io/?843fe20da241addbe0bc67cd37c4d60d (see the "PR backlog dashboard" and "Issue backlog dashboard": the numbers are the argument for doing something: 70 open PRs (60% older than 1 year), and 886 open issues of which 743 (84%) have had no activity in over 2 years -- the oldest is 21 years old, and 246 still sit at "to-triage". No one can sweep that by hand. It's labour at scale, not knowledge (unfortunately)) Examples on GitHub: Draft PRs on my personal fork so the diff and footprint are fully reviewable (not proposed to apache/jmeter yet): #1 Magpie adoption + JMeter config: https://github.com/milamberspace/jmeter/pull/1 #2 AGENTS.md build notes (see below): https://github.com/milamberspace/jmeter/pull/2 On the footprint, it is minimal. 21 committed files: ~550 lines of JMeter-specific config, plus one magpie-setup doc (~4.7k lines of *markdown*, not code) so a fresh clone can re-fetch. The other 68 skills live in a gitignored snapshot -- never in git. Removal is one command (/magpie-setup unadopt). On the context window: agreed it matters, and it's handled by design: skills load on demand. Only a one-line description per skill sits in the always-on index (~1% of the window); a skill's full instructions enter context only when a maintainer runs it. And it is not generic knowledge -- what it encodes is ASF/JMeter-specific: Vulnogram CVE flows, reading private@ via the PonyMail archive, [VOTE]/[RESULT] tally against the binding roster, our own CI-check map. The "how to write a JUnit test" parts are not what it adds. On CLAUDE.md / AGENTS.md : strong +1, and independent of the Magpie decision -- so I already did it: PR #2 adds a short AGENTS.md section with the gradle tasks and the test-JDK flags you mentioned (-PjdkTestVersion / -PjdkTestVendor), with a copy-paste example. It stands on its own whatever we decide on Magpie. I went with a single AGENTS.md rather than a parallel CLAUDE.md on purpose: AGENTS.md is a vendor-neutral file most agents already read (Codex, Gemini CLI (Antigravity), Copilot and Claude Code, etc.), so need CLAUDE.md (Claude will manage with AGENTS.md). On microsoft/apm and your (Vlad's) agent-packages : it's complementary, not competing. I agree Magpie doesn't try to do that. Magpie is a focused set of ASF committer/PMC/release/security workflows, not a general package manager or a translation toolkit. It even has a "trusted skill sources" mechanism to pull external packages in, so your EN/FR/RU translation skills could sit alongside it. In addition, Magpie, it's a young project (v0.1.0). It grew out of real ASF maintainer automation most directly Apache Airflow's tooling plus a framework built for ASF security-issue handling, generalised into a governance-agnostic framework aligned with the ASF Responsible AI Initiative (see [email protected] mailing-list on Ponymail). MISSION.md is the draft proposal to make it a TLP. I've CC'd Jarek because I believe he is one of the people behind Apache Magpie that promote it, and he might be able to help us with adopting Magpie in JMeter (in case my email isn't clear enough...). Current status with Magpie in JMeter: Only pr-management, issue and security are wired so far, release-* skill isn't enabled yet, though it's the part I think could most help prepare the next releases (specially for try to release minor/major versions more regularly), for this point if you aren"t any objection, i will activated the release skills before the new release (at least for evaluate/test these skills) Antonio, Vladimir (and Jarek), your comments, vote (pmc), etc are welcome. Thanks, Milamber On Tue, Jul 07, 2026 12:44 PM, Vladimir Sitnikov < [email protected]> wrote: > >Do you have example from JMeter gitHub? > > +1 > > >I've prototyped the adoption on a branch: it works cleanly with our GitHub > >Issues, the dev@/private@ lists (via the ASF PonyMail archive), and the > ASF > >CVE tooling. > > Can you share the branch and the workflows Magpie improved? > > >I open a PR, I wanted to check with you: are the PMC and committers > >OK with integrating Magpie (directly the Method 3 — git branch - main) ? > > Frankly, I am pessimistic regarding Magpie even though I am optimistic > regarding LLM. > If the changes are minimal, I won't object. > If Magpie occupies the context window with stuff that LLMs already know by > heart, then, well, that is just a waste of resources. > > --- > > I think we should add CLAUDE.md / AGENTS.md to explain JMeter specifics to > agents. > For instance, we have a build flag to configure "test jdk version". Agents > should know it so they know the way to trigger tests with different JDK > versions. > > Then, I think we should consider https://github.com/microsoft/apm for > "agent package" (~skill) management. > For example, I have a set of skills for creating English, French, and > Russian texts (see > > https://github.com/Netcracker/qubership-ai-packages/tree/main/agent-packages > ), > and they would be helpful when creating/updating the translations. > > I do not think Magpie helps with that though. > > Vladimir >
