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