Also, I realized—it's often the thing you assume everyone follows, but then you discover others focused on different things. My apologies, I should have explained it better.
So here is some more information on what it "really means". Where we are * Our "airflow-s"—our private security repo—switched completely to using Magpie version a few weeks ago. I completely run syncing and importing security issues using it - we have a number of improvements since - for example as of yesterday there is no more need to copy CVE entries manually by Release Mnagers (Which was pretty much last, annoying manual step in the process). They all sync automatically now. * I just rebased https://github.com/apache/airflow/pull/66677 (the third or 4th time already) while continuously re-applying our custom overrides to the generic skills (I kept them updated in parallel). I am running the triage session now with the latest version from "steward/magpie" - to demonstrate that it still works—even better, as we have incorporated several improvements from others. I managed to gather an amazing roster of founding ASF members for "Magpie" (technically only ASF members should start the new PMC). All of them focused on the mission [1]: with the motto of"Give maintainers time back, so they can do what matters.". See the current roster below. And we immediately benefited from this "common PMC" approach and multiple contributors. Just last week we received many contributions from "outside" of Airflow (including several from Yeaonuk Choo, André, and others in the Airflow community: * Paul King from Apache Groovy contributed (and continues to improve) a complete set of "issue triaging" skills, which we had deferred. It turned out that Groovy uses a very similar SKILL - based approach for issue triaging (this is the problem they were solving), and Paul simply contributed all of it. We are currently working on and improving it, and soon I will be able to run the first issue-triaging session to review and clean up our issues (we are currently testing to apply Airflow overrides; later, we might turn this into issue cleanup/review campaigns. * Justin McLean, VP of Incubator, discussed license checks, policies, and most recently, the complete set of evaluations. All the SKILLs we currently have are now automatically tested with expectations and consistency checks (today, he even fixed some inconsistencies in our PR triage thanks to the evaluations). * André and Yeonguk - contributed many changes to better organize the mission and automatically validate and optimize SKILL usage (including ensuring minimal token use and that SKILLS retain context * Andrew Nesbitt—a friend from OSSF with whom we collaborate in the security area - reviewed the skills using his security tooling and contributed several protections against clever prompt injections and other novel AI security issues And we have not even started yet :) *ASF members for the roster:* - Jarek Potiuk (potiuk) — Airflow PMC - Piotr Karwasz (pkarwasz) — Log4J PMC - Elad Kalif (eladkal) — Airflow PMC - Matthew Topol (zeroshade) — Arrow PMC, Iceberg PMC - Pavan Kumar Gopidesu (gopidesu) — Airflow PMC - Amogh Desai (amoghdesai) — Airflow PMC - Andrew Musselman (akm) — Mahout PMC - Justin Mclean (jmclean) — Incubator PMC, Training PMC - Jean-Baptiste Onofré (jbonofre) — Incubator PMC, Polaris PMC, … - Paul King (paulk) — Groovy PMC, Grails PMC, Incubator PMC - Evan Rusackas (rusackas) — Superset PMC - Russell Spitzer (russellspitzer) — Incubator PMC, Polaris PMC, Iceberg PMC - Ismael Mejia (iemejia) — Beam PMC, Incubator PMC - Zili Chen / tison (tison) — Pulsar PMC, Curator PMC, ZooKeeper PMC, … - James Fredley (jamesfredley) — Grails PMC - Calvin Kirs (kirs) — Doris PMC, Geode PMC - Rich Bowen (rbowen) — Incubator PMC, ComDev PMC, … - Mike Drob (mdrob) — Accumulo PMC, Curator PMC, HBase PMC, Lucene PMC, Solr PMC - Craig L Russell (clr) — Security Team, Incubator PMC, ComDev PMC, … The named PMC roster will accompany the resolution at the time of the vote. There are collaborators who are not ASF members yet (wink) but who have already contributed and will be involved as collaborators on the project from day one: - André Ahlert Junior — @andreahlert - Bartosz Sławecki — @johnslavik - Yeonguk Choo — @choo121600 - Shahar Epstein — @shahar1 - Vincent Beck — @vincbeck - Buğra Öztürk — @bugraoz93 [1] https://github.com/apache/airflow-steward/blob/main/MISSION.md J. On Sun, May 17, 2026 at 10:40 PM Jarek Potiuk <[email protected]> wrote: > And just to add. > > The https://github.com/apache/airflow a/pull/66677 is really the best > "demonstrate" what it means: > > 1) remove of all the skill code (or markdown - whatever you name it) -> > that can be generalized > 2) extraction of Airflow-specific flows (for example splitting releases to > providers/airflow-ctl/airflow) into "overrides" > 3) leaving a "setup-steward" code committed - this is a "bootstrap" part > that comes direclty from "Steward" (soon likely it will be "/magpie-setup" > ) -> to be able for anyone of our maintainers or contributors to setup > magpole on thoer onw machine by issuing "/setup-steward" commad > > J. > > > On Sun, May 17, 2026 at 10:30 PM Jarek Potiuk <[email protected]> wrote: > >> Good. Thanks Vikram for raising the points. Let me answer them in detail. >> I think we all deserve it. >> >> 1. I assume these projects can grow independently and that the Airflow PMC >> can at some point choose not to use the Apache Steward work. >> >> Airflow is the most prominent user of it and it will stay like that - I >> hope. Though >> We already have Groovy and Burr as users, and I am talking to Python Core >> The team should also use it; they were very interested. >> >> I think the design allows "any" adopter to implement it easily. >> their own customization - but keep them independently maintainer - with >> limited "departure" from the common workflows. >> >> If some of the changes will make Airflow PMC not want to use it - so be it >> this might become independent set of skills. in Airflow and there is no >> obligation for Airlfow to use "Magpie". There is absolutely no >> "obligation" to >> Use Magpie, but the existing customization/override framework already >> allows it. >> to have very, very custom workflow modification. The fact that it is all >> written as >> English skills: our override might simply say "For point 10 in this >> workflow, >> We do this and that instead of, or in addition to, the generic workflow. >> We >> I already do that for "airflow-s" and the security issues workflow. >> >> >> 2. The security triage and the PR triage work are independent of each >> other >> and using one does not preclude or presume the use of the other. >> >> Absolutely - those are independent "Family" of skills following the same >> pattern - coming from different work (mostly because one of them is >> in private repo and the other is in private) - the "private" part of >> configuration >> remains "private" in "airflow-s", also "airflow" specific one remains in >> "airflow" repo - what is extracted is the "reusable" PR which I continue >> to rebase >> https://github.com/apache/airflow/pull/66677 - and the content of the >> SKILLS >> remain synced between the two. >> >> 3. The AI skills used for either or additional use cases such as issue >> triage can be independently expanded by the Airflow PMC without needing >> changes in Steward. >> >> Absolutely - they are already independent and a "separate family of >> skills". >> This is already built in "steward/magpie" and the PR >> https://github.com/apache/airflow/pull/66677 is implementing that. >> This is modelled very closely on Helm's "kustomize," which we convert >> our Chart to in 2.0 - where you can have "overrides" implemented in your >> "custom" adoption - and those overrides are adding "Airflow-specific" >> logic to what is implemented as "generic workflow" - and "Magpie" will >> Apply the custom logic as an override when running the generic skills. We >> even >> Have skills that allow contributing local changes back to "Magppie" >> if we think it is good - and will apply generalisation rules, we should >> make them >> configurable. So no flexibility is lost, no Airlfow-variant is lost. >> >> For example - in our security skills, we use the "Release Plan" >> configuration >> - i.e. from where we retrieve who the next release manager is for >> Providers, Airflow, >> Airflow-CTL: all that is used to automatically assign the release manager >> of Airflow (as >> configured in Cwiki) - to security issues merged in a specific release. >> This is all implemented as "override" in "airflow-s", extending the >> functionality of >> generic "Magpie" "security" family of SKILLS. We are discussing how to >> make >> families even more generic - but all that will come as something we will >> be able to automatically upgrade to the new version of Magpie. >> >> I've done a full migration to the upgraded set of skills about five times >> now, which >> It is implemented as agentic instructions to move and rename things, and >> it works >> wiithout any problems that Agents would not be able to resolve. >> >> 4. The AI skills can be independently extended for specific providers by >> the Airflow PMC and/or the steward of the specific provider. >> >> Absolutely. This is already happening and >> https://github.com/apache/airflow/pull/66677 already does it (ad I will >> keep on managing it until it gets merged). It shows the overrides Airflow >> implements that are specific to Airflow - and departure from the original >> workflow. Moreover - we have agentic skills - run during the upgrade >> that are running "reconciliation" - so - if we decide to do upstream >> changes >> to Magpie, and decide to switch to new version of it - those local changes >> will be automaticlaly reconciliated, conflicts resolved and our new >> version of >> custom "workflow" modification to match what we have will be pretty much >> automatically (with review) done by the agent. >> >> This is the power of writing intention results of English skils. IT's so >> much better >> than reconciling conflicts in "programming language" >> >> It just works. I've done it already 10 times or so. >> >> I hope it can alleviate the concerns. >> >> Jarek >> >> >> >> >> On Sun, May 17, 2026 at 9:50 PM Vikram Koka via dev < >> [email protected]> wrote: >> >>> Jarek, >>> >>> At this point, I don't have a complete understanding of what is being >>> proposed here. >>> I therefore cannot agree to the lazy consensus. >>> >>> I do believe there is valuable work being done here, but it has moved >>> very >>> quickly and the flurry of emails has left me confused. >>> Is there a composite document outlining what is being proposed? >>> >>> I am especially curious about a few things, since this seems to have >>> grown >>> in a couple of different directions: >>> 1. I assume these projects can grow independently and that the Airflow >>> PMC >>> can at some point choose not to use the Apache Steward work. >>> 2. The security triage and the PR triage work are independent of each >>> other >>> and using one does not preclude or presume the use of the other. >>> 3. The AI skills used for either or additional use cases such as issue >>> triage can be independently expanded by the Airflow PMC without needing >>> changes in Steward. >>> 4. The AI skills can be independently extended for specific providers by >>> the Airflow PMC and/or the steward of the specific provider. >>> >>> Best regards, >>> Vikram >>> >>> >>> Best regards, >>> Vikram >>> >>> >>> On Fri, May 15, 2026 at 7:11 PM Jarek Potiuk <[email protected]> wrote: >>> >>> > Hello Dear community, >>> > >>> > I've been discussing it for a while and I've been busy working >>> > on "apache-steward" repo with a few capable individuals, so I hope >>> > this is not a surprise and I have not seen any objections so far. >>> > >>> > In the PMC's [DISCUSS] thread from 28 April 2026 >>> > ("[DISCUSS] Spinning off Security Triage + PR Triage + Review from >>> > Airflow PMC"): no objections were raised to migrating our triage and >>> > security tooling to a separate PMC, and Jens explicitly agreed it >>> > can and should be shared. >>> > >>> > Since that thread: >>> > >>> > - The new PMC has been renamed from "Apache Steward" to Apache >>> > Magpie (the working repo keeps the `steward` codename). Trademark >>> > feedback drove the rename; the trademark check is filed at >>> > PODLINGNAMESEARCH-252. >>> > - The Top-Level Project Proposal is on cwiki under ASF Private >>> > ("Apache Magpie (former Steward): Top-Level Project Proposal"). >>> > - The repo `apache/airflow-steward` was set up with >>> > `[email protected]` / `[email protected]` >>> > notification targets — i.e. currently under Airflow PMC oversight >>> > pending Magpie's board approval. >>> > - Magpie's establishment is on track for the 20 May board meeting. >>> > >>> > Calling [LAZY CONSENSUS] on the following: >>> > >>> > The Apache Airflow PMC indicates its intent to hand ownership of >>> > `apache/airflow-steward` (the security-issue and PR-management >>> > skill packs, plus the supporting tools) over to the Apache Magpie >>> > PMC at the moment Magpie is established at the 20 May 2026 board >>> > meeting. Airflow continues as a primary downstream user via the >>> > framework's adopter model (project-config overrides + >>> > snapshot-based adoption). Day-to-day Airflow triage workflow is >>> > unchanged; the security tracker (`airflow-s/airflow-s`) and >>> > `[email protected]` channel stay with the Airflow PMC. >>> > >>> > Lazy consensus closes 72 hours from this message — i.e. roughly EOD >>> > Monday 18 May 2026 UTC. Silence = agreement per usual lazy-consensus >>> > convention. Reply with -1 <reason> (or any concern) if you'd >>> like to >>> > adjust scope or discuss further. >>> > >>> > Thanks, >>> > Jarek >>> > >>> >>
