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 >> > >> >
