> No limit for public forks does change things- i will re-read with that in mind
Yeah. Precisely - the table they show is a bit ambiguous in that regard. In our initial PMC slack conversations **I remembered** hitting the limits myself, so my initial proposal was including it, but I double checked and verified that what I remembered was hitting the limits in our private "airflow-s" repository, where we keep security issues, which is not part of the "apache" organisation. BTW. This is one of the reason why GitHub Private Security Reporting does not have CI enabled - because the repos where you can open issues are private, and it would be a very easy "workaround" if it was possible to fork your public repo and have unlimited CI in its private fork :) So I completely removed the 2000 minutes from the reasoning. It's in the AIP only as historical reference - but yeah I see how it can be confusing (and I can remove it entirely if it is confusing). Sorry if that was creating confusion. J. On Sat, Sep 19, 2026 at 3:13 PM Ash Berlin-Taylor <[email protected]> wrote: > 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] > >
