Thanks Ash and Dennis - this is exactly the kind of pushback I hoped for, and I'd love to hear from more people, especially those who are not committers. I am looking at the concerns seriously, but I think both of you overestimate the actual impact on contributors. Let me explain why.
Dennis: It's really not *that* bad. The contributor experience is a single command, run once per fork: gh workflow enable ci-amd.yml -R <your-user>/airflow That's it. No sorting through 50 workflow files, no fork settings pages, and the comment we post on the drafted PR will contain that exact line. We can even wrap it in a breeze command that enables the workflows and audits the fork - checks that Actions are on, the right workflows are active, the branch is rebased - and tells you exactly what is missing before you push. We will also adjust triggers so that a plain push to a branch in a fork runs CI there - no PR against your own fork needed. Everything else we *already* expect from contributors today: green CI, following the guidelines. The only new thing is "enable workflows in your fork". The monitor is not hand-wavy - it's deterministic and cheap. The GitHub API tells us whether workflows in a fork are enabled (state "disabled_fork" vs "active") and whether the run for a given SHA is green. We can check it, and when someone enables workflows, ping them to rebase and undraft. A few REST/GraphQL queries per PR, no build time. On "my PRs sit in CI for an hour": that is precisely the problem. Your jobs are not *running* for an hour - they are *waiting* in the ASF queue. I have a script that checks ASF-wide GitHub Actions usage and Airflow is routinely at the very top by number of jobs. We stay within ~6 full-time runners, which is below the limits Infra set, so we don't *have* to do anything - but this change would cut the number of jobs we run significantly, and that is what shortens your hour. You are right on the ratio - 4392/31 is ~142x, not 60x. I'll fix the AIP. Ash: "Want to contribute? pay" - you are not paying. You are just going slower. I was wrong on the 2000 minutes earlier in slack and corrected it in the AIP and in my mail: there are *no* minute limits for public repos, so a flaky test or a broken main costs you a re-run, not quota. The only limit is 20 concurrent runners per account. That has a nice property: someone opening five large core PRs in a row waits a long time for all of them to go green, while a one-line docs fix is unaffected. This is "self-regulate the pace", not "pay to play". Please do read the AIP section on this - time is the only factor, money is not involved at all. On "lots of work before we might reject the idea": the work is enabling workflows once with single command. The risk of a PR being rejected on design grounds exists today in exactly the same way. On 6.3 (gate on triaged issues): I am fully supportive and would be happy to see you write it up as a separate AIP - I'd even propose doing it spec-driven. But note that it is a far more impactful change to how we work than AIP-120: AIP-120 changes nothing in our process except where CI runs, while issue-gating changes how features and fixes get approved. The two are independent and complementary. The other side - the queue itself - is AIP-118, which Shahar and I are working on; feedback there is very welcome too. The root cause of the queue is that there is no prioritisation in the ASF pool - not between committers and external contributors, and not between projects. Infra is exploring GitHub Enterprise multi-tenancy, but that is months away and comes with its own limits (a fixed runner count for Airflow shared by everyone could make things worse). With 118 and 120 together we get three tiers: committers and canary on bigger self-hosted runners, approved contributors on the ASF pool, new/occasional contributors on their own free runners. If it works, the plan is to share the approach with other PMCs, which makes the middle tier far less prone to queueing. J. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
