Yup, broadly in agreement too. > On 2 Nov 2026, at 08:05, Vincent Hsiao <[email protected]> wrote: > > 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 >>> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
