Very nice initiative - good stuff Bruno :). I love to hear JMeter wants to use Magpie!
We are a young project indeed. And I looked through your gist - it is very accurate in terms of assessment of where we are and how Magpie will be useful for you. I will reiterate it with my own words now to underline the important points. 1) We move fast - I am literally today planning to start voting on the first official release today, aiming for completion by the end of this week 0.1.version 0.1.0 should be officially published on SVN 2) We became a TLP two weeks ago :) 3) We already have very comprehensive documentation on adoption, education and which skills can be used where: https://magpie.apache.org/ 4) Magpie is not "exclusive"; we designed it so you can adopt it totally independently from any other SKILLS - whether written manually or adopted from elsewhere 5) We have some really good set of ASF-related skill families as well - including releasing, contributor onboarding etc - look at our landing page for the skill families we have 6) We even have meta-skills that allow you to a) write your own skills b) override and extend parts of Magpie SKILLS (the nice thing about Magpie SKILLS is that they are override'able by default - you can ask your client to have local modifications of the skills coming from Magpie c) reconciliation - whenever you upgrade to newer version of Magpie, it will automatically reconcile your local modifications with upstream changes d) ssuper easily upstream your changes back to Magpie :) The last part responds well to the part of argument of yours in the gist, that we are at the stage that shaping Magpie is "easy" - being one of the early users you can definitely help us to make Magpie more useful for projects like yours and we welcome such contributions. So... I am all for it - and happy to help :) J. On Tue, Jul 7, 2026 at 6:14 PM Bruno Demion <[email protected]> wrote: > 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 >> >
