Hey Ash, > The issue is PRs being created and not reviewed. Making contributors run PR does absolutely nothing to address this backlog, so I don’t see how it helps or why we want this?
The actual impact I expect is slowing down big PR iteration, not preventing the opening of more PRs. It will slow them down, and the slowdown will be greater the larger and more "core" the PR is. If someone has 10 large core PRs, they will be able to iterate on them (collectively) up to ~15x slower than if they used ASF CI and rebased/fixed those 5 CIs simultaneously. The feedback loop will also become sequentialized rather than parallelized. For example, if a contributor rebases at the same time 10 large PRs, it will take roughly ~36 hours for those PRs to complete their builds. Small PRs—such as those touching a single provider—will be almost unaffected. They might even run faster than today (!) if there is a queue on the ASF runner. I believe this directly aligns with our goals by introducing natural friction (context switching, wait times, flakiness frustration) to discourage opening sensitive, large PRs while incentivizing smaller ones. We achieve this indirectly: not by telling people to dial down, but by regulating the feedback loop to slow down the churn. The iteration time and time-to-green will be significantly worse for the types of PRs we want to receive less frequently. Contributors will adapt their behavior simply because smaller PRs will be more convenient. And having many small PRs instead of many big ones naturally decreases the work maintainers have to do. This decrease comes not from a smaller number of PRs but from less time spent on them. Possibly most of those PRs will be practically "auto-mergable" with agentic review and some harnesses added by us. Of course, this isn't an exact science. It depends on review times, errors, required iterations, flakiness, working hours, and whether contributors work in bursts or have continuous time to iterate. Given these variables, I see this as a logical next step to implement after limiting PRs, allowing us to evaluate the impact empirically. There is quite a bit of "Leap of faith'" in my projections. But I think they are pretty sound. While it's difficult to predict precise metrics—much like turbulent flow theory—my intuition suggests this will at least halve the average size of incoming PRs, shifting the balance heavily from "core" and "dev" PRs toward provider PRs. (Side note: I am seriously considering changing our approach so we don't run full builds for Breeze and related tooling on every iteration, perhaps replacing it with a forced final check. I want to encourage dev-related contributions; we currently have about 10 people actively contributing to the dev environment, many of them new, which has been great for the developer experience.) > How does GH show/surface the reporting of these GHA runs? I assume we’ll still need to run the tests again on our fork before we merge? How do we trigger those GHA runs? Contributors will simply push to their branches as they do today when rebasing. No change. How contributors see CI will depend on the stage they are in: - Before opening a PR to Airflow: They can view builds in the "Actions" tab of their own repository, or open a PR in their fork (as suggested by Christos) to get the standard PR UI for restarting jobs. - Once opened to Airflow: Under my proposed design, the PR in the Airflow repo will receive a mirrored status from their remote CI run. It will update periodically (e.g., every 15 minutes). Clicking the status will link directly to the job running in their fork. We could also mirror individual job statuses if desired - then it will be even closer to the current experience where we see individual job status directly in PR. There is no strict need to re-run the tests on the Airflow repo, though we could configure optional workflows—for example, automatically triggering a standard ASF CI run or rebase once a maintainer approves the PR (and then we go back to 100% today experience) >From a maintainer's perspective, the experience remains essentially the same (merge on green), with the only decision being how detailed the mirrored status reporting should appear on our end. Best regards, Jarek On Tue, Sep 22, 2026 at 12:38 PM Ash Berlin-Taylor <[email protected]> wrote: > Allowing them to run CI on their forks and forcing them to are separate > things. > > My main complaint against this idea is it feels like it is optimising for > the wrong thing. > > The issue is PRs being created and not reviewed. Making contributors run > PR does absolutely nothing to address this backlog, so I don’t see how it > helps or why we want this? > > How does GH show/surface the reporting of these GHA runs? I assume we’ll > still need to run the tests again on our fork before we merge? How do we > trigger those GHA runs? > > -ash > > > On 22 Sep 2026, at 11:18, Jarek Potiuk <[email protected]> wrote: > > > > So .. as discussed in the other thread about PR limits.. This one also > has > > one advantage, that contributors who will hit their limits will be able > to > > run CI on their branches, by simply pushing branches to their repos (and > > either just looking at Actions tab or creating self-repo PRs). > > > > I think it's largely a no-brainer. > > > > We can implement it as a next step after limiting the PR number. As > > discussed in the other thread, I'd prefer to first add the PR number > limit > > and some time after, also move CI. That has double advantage - we can see > > impact of each of those separately, and we will have **two** > opportunities > > to educate our contributors. First the "heavyweights," then everyone > else. > > > > J. > > > > > > J. > > > > > > On Sat, Sep 19, 2026 at 7:41 PM Jarek Potiuk <[email protected]> wrote: > > > >>> I noticed you mentioned the "Per-contributor pull request caps" as an > >> alternative. If my memory serves me correctly, there was a thread > >> about that a little while back and it seems a lot of people were in > >> favor of it. Is that an ongoing discussion or has it been ruled out? I > >> don't think the two are mutually exclusive. I wonder if a cap would > >> help encourage contributors to focus on quality over quantity and > >> getting contributions over the finish line before jumping to something > >> new. That might constitute a separate discussion though. Just my two > >> cents. > >> > >> Yeah. Not mutually exclusive and yeah we already agree to implement it. > >> But that is waiting for .That is waiting for my .asfyaml PR to be > >> merged. That is waiting for my .asfyaml PR to be merged: > >> https://github.com/apache/infrastructure-asfyaml/pull/111. I've been > >> relentlessly pushing towards getting it merged (same a a number of other > >> PRs) - including creating this workflow > >> https://github.com/apache/infrastructure-asfyaml/pull/127 and this > SKILL > >> https://github.com/apache/infrastructure-asfyaml/pull/133 for the infra > >> people to be able to test any .asfyaml changes in minutes rather than > >> hours. > >> > >> The last two PRs were merged just a few days ago - and I was hoping the > >> first PR would finally be merged quickly, especially since I tested all > of > >> them with my skill and even fixed some issues. Some of those PRs waited > for > >>> 6 months. > >> Any nudge from people still waiting for this feature would be welcome. > >> > >> I can only do as much .... > >> > >> J. > >> > >> > >> On Sat, Sep 19, 2026 at 6:44 PM Christos Bisias <[email protected]> > >> wrote: > >> > >>> Based on these comments from Ash > >>> > >>>> Relevant is SQLAlchemy’s experience if trying the no pr without issue > >>> triage: https://fosstodon.org/@zzzeek/117298404897300953 > >>> > >>> and > >>> > >>>> Imagine this, someone creates a PR, it gets converted to draft, they > go > >>> to all the effort of setting up GHA on their fork, a few rounds to get > >>> tests passing, and only then to get the attention of a committer to be > >>> told > >>> “sorry, no this can’t work/this is by design” and the PR gets closed. > >>> Sounds like a _perfect_ way to put people off contributing ever again. > >>> > >>> we might be able to reduce the number of unnecessary PRs by moving the > >>> discussion to issues. If there was a separate issue tracker which was > >>> meant > >>> just for contributors and proposed fixes / changes, feedback could > start > >>> over there before people spend time working on something. PRs would > have > >>> to > >>> be associated with an issue and be opened only after someone has > looked at > >>> the issue and there was consensus that the proposed changes are valid. > >>> > >>> It's not relevant to Jarek's AIP but I'm just throwing an idea. > >>> > >>> Christos > >>> > >>> On Sat, Sep 19, 2026 at 7:38 PM Justin Pakzad <[email protected]> > >>> wrote: > >>> > >>>> Thanks for putting this together, definitely in favor of this. While > >>>> it might be a bit more time consuming for contributors, I believe it's > >>>> justified and don't see it as a big barrier, especially if the process > >>>> is as simple as you stated in one of your previous messages (e.g., no > >>>> additional PR needed against the fork). > >>>> > >>>> I noticed you mentioned the "Per-contributor pull request caps" as an > >>>> alternative. If my memory serves me correctly, there was a thread > >>>> about that a little while back and it seems a lot of people were in > >>>> favor of it. Is that an ongoing discussion or has it been ruled out? I > >>>> don't think the two are mutually exclusive. I wonder if a cap would > >>>> help encourage contributors to focus on quality over quantity and > >>>> getting contributions over the finish line before jumping to something > >>>> new. That might constitute a separate discussion though. Just my two > >>>> cents. > >>>> > >>>> - Justin P > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >
