I think separating development and CI infrastructure proposals from AIPs makes sense.
They focus on different aspects of the project. fat-catTW Shahar Epstein via dev <[email protected]> 於 2026年11月1日週日 下午11:11寫道： > +1 from me, I think that it makes sense to separate the development > proposals from the product itself. > > > > Shahar > > > On Sun, Nov 1, 2026, 16:18 Jarek Potiuk <[email protected]> wrote: > > > Hello everyone, > > > > This is the follow-up to the discussion I reopened on 2026-10-27 [1]. > > In that thread I proposed to stop treating changes to how we develop > > and test Airflow (CI, development environment, test infrastructure) > > as AIPs, and to give them a separate place on the wiki. Nobody > > objected so far, but since no-objection does not mean consensus, > > as we learned recently - before I start a formal vote, i wanted to turn > it > > into a PROPOSAL so that it has clear subject and separate thread. > > > > Why > > --- > > > > The AIP page [2], in "What is considered a major change that needs > > an AIP?", gives two criteria. An AIP is needed for: > > > > * "Any major new feature, subsystem, or piece of functionality" > > * "Any change that impacts the public interfaces of the project" > > > > and it lists what the public interfaces are: > > > > * Airflow DAG DSL components: DAG, XCom, TaskInstance and context > > * The Web UI > > * Core operators (BaseOperator, SubDagOperator, SensorOperator) > > * REST endpoints > > * Command line tools and arguments > > > > None of the proposals listed below meets either criterion: > > > > * They are not a feature, subsystem or functionality of Airflow. > > Nothing they introduced ships to users in any Airflow release: > > the linter setup, Breeze, the CI image, the move away from > > Travis, pytest, the system and performance test frameworks, the > > self-hosted runners, the guardrails of the AWS account that hosts > > them, and running CI in contributors' forks all live in our > > repository and infrastructure, not in the product. > > > > * They change none of the interfaces listed above. No Dag authoring > > component, UI page, operator, REST endpoint or CLI command > > behaves differently because of any of them. > > > > What they do change is how we, contributors and maintainers, work: > > how code is checked, built and tested, and where CI runs. Those are > > decisions about how the project operates. We made them AIPs only > > because the AIP page was the one place we had to describe a design > > and record a decision. As the AIP-120 discussion showed, that > > causes confusion: about what is being decided, about who is > > affected, and about which kind of vote applies. An AIP vote on a > > code change lets a single binding -1 block it, while a decision > > about how the project operates is a procedural, majority vote [3]. > > > > Moving them to their own section makes the AIP list again what the > > AIP page says it is: changes to Airflow itself and its public > > interfaces. > > > > What I propose > > -------------- > > > > 1. A new wiki section, next to the AIPs: "ADIP - Airflow Development > > Improvement Proposals". The name is a placeholder; if you have a > > better one, say so in this thread and we will go with the one most > > people prefer. > > > > 2. ADIPs cover proposals that only change how the project is > > developed, tested and built: CI, the development environment, > > static checks, test infrastructure and the infrastructure that > > runs CI. Anything that affects users (installation, images, > > providers, public interfaces) stays an AIP. > > > > 3. ADIPs are decided like any other decision about how the project > > operates: discussion on dev@, then [LAZY CONSENSUS] or a > > procedural [VOTE] (majority of binding votes, at least 3 binding > > +1 and more binding +1 than -1) [3]. > > > > 4. The CI / development AIPs listed below move to the new section and > > are renumbered from 1. Nothing about any decision already made > > changes: each page keeps its content, history and discussion > > links. > > > > 5. Old links keep working: > > - every moved page keeps its Confluence page ID, so all > > ".../pages/<id>/..." links (the form used in most of our mails) > > resolve to the moved page; > > - every new title says "(formerly AIP-N)"; > > - a stub page stays under each old title, saying "Moved to > > ADIP-N" and linking to the new page, so links by the old title > > and old bookmarks still land somewhere useful; > > - the old AIP numbers are retired and never reused. > > > > 6. The AIP index page gets a short note pointing to the ADIP section. > > The index lists are generated from page labels, so the moved pages > > get an "adip" label instead of the AIP state labels, and they drop > > out of the AIP lists automatically. > > > > Proposed renames > > ---------------- > > > > Numbered in the order of the original AIP numbers. > > > > ADIP-1 (formerly AIP-4) Automation of System Tests > > was: AIP-4 Automation of System Tests [Deps: AIP-47] > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/93324355 > > > > ADIP-2 (formerly AIP-6) Enforce the usage of a code formatter & linter > > was: AIP-6 Enforce the usage of a code formatter & linter > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/99844429 > > > > ADIP-3 (formerly AIP-7) Simplified development workflow > > was: AIP-7 Simplified development workflow > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/99844641 > > > > ADIP-4 (formerly AIP-9) Automated Dependency Management > > was: AIP-9 Automated Dependency Management > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/100828074 > > > > ADIP-5 (formerly AIP-10) Multi-layered and multi-stage official Airflow > > CI image > > was: AIP-10 Multi-layered and multi-stage official Airflow CI > image > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/100828709 > > > > ADIP-6 (formerly AIP-23) Migrate out of Travis CI > > was: AIP-23 Migrate out of Travis CI > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/122916333 > > > > ADIP-7 (formerly AIP-27) Migrate to pytest > > was: AIP-27 Migrate to pytest > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/132321242 > > > > ADIP-8 (formerly AIP-47) New design of Airflow System Tests > > was: AIP-47 New design of Airflow System Tests > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/199532973 > > > > ADIP-9 (formerly AIP-59) Performance tests framework > > was: AIP-59 Performance tests framework > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/278465469 > > > > ADIP-10 (formerly AIP-118) Self-hosted runners for Apache Airflow CI > > was: AIP-118 Self-hosted runners for Apache Airflow CI > > https://cwiki.apache.org/confluence/x/-JXwGg > > (its appendix page moves with it, as > > "ADIP-9 Appendix - evidence and implementation details") > > > > ADIP-11 (formerly AIP-119) Anomaly monitoring and guardrails for the > > Airflow AWS account > > was: AIP-119 Anomaly monitoring and guardrails for the Airflow > AWS > > account > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974695 > > > > ADIP-12 (formerly AIP-120) Run CI for external contributions in > contributor > > forks > > was: AIP-120 Run CI for external contributions in contributor > forks > > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711 > > > > These stay AIPs, although they are close to the line, because they > > affect users: AIP-8 (providers as separate packages), AIP-11 (landing > > page), AIP-26 (production Docker image) and AIP-95 (provider > > lifecycle). > > > > AIP-47 (System tests) is the most borderline of the moved items, since > > User docs take their examples from system tests. If you think it, > > or any other entry, belongs on the other side, please say so in the > > thread and I will adjust the list. > > > > The vote proposal > > -------- > > > > This would be a procedural vote: majority of binding votes, at least 3 > > binding +1 and more binding +1 than -1 [3]. Everyone is welcome to > > vote; votes from PMC members are binding. > > > > I realise this is a busy time: the 3.4.0 release vote, provider > > releases, the Summit Reconnect on 4-5 November. If you need more time > > to have a look, say so, and I would like to start a vote on it this week. > > But not by > > much: I fear we will have to act quickly in the "Your PR, your CI" > > area (AIP-120, which would become ADIP-12), given the pressure on the > > shared ASF runners and on our reviewers, and our quest to limit > > big PRs and encourage small ones. > > > > For the same reason, I would like to start the vote on "Your PR, your CI" > > (formerly AIP-120 - possibly future ADIP-12) soon, > > without waiting for this one to complete. The two are > > independent: that vote decides whether we run CI for external > > contributions in contributors' forks; this one only decides where > > such proposals live on the wiki and how they are numbered. > > > > Let me know if that proposal makes sense and whether you have > > any concerns. > > > > J. > > > > [1] https://lists.apache.org/thread/h5qsfqthmsqoh5j7wyy12r90mnnvz8kt > > [2] > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals > > [3] https://www.apache.org/foundation/voting.html > > >
