No limit for public forks does change things- i will re-read with that in mind
> On 19 Sep 2026, at 14:01, Jarek Potiuk <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
