+1 for a PR limit at 5, with an exclusion list/override for folks that makes sense for
On Wed, Sep 23, 2026 at 8:05 AM Zach Gottesman via dev < [email protected]> wrote: > I think the proposal makes sense. In particular, I think Jarek’s point > quoted below especially true: > > “ > > *We also need to adapt to the reality where generating code is fast > andcheap, meaning a submitted PR no longer guarantees that someone > understandsAirflow or is genuinely invested.*” > > To that point: in my experience (anecdotal), I’ve noticed in the past 6 > months there’s a large shift in focus for contributors of any project - > Airflow or otherwise - towards adding shiny new features. That is not > necessarily a bad thing, but IMO the increase in “fun feature” PRs tends to > increase the projects’ complexity while making it more difficult for > maintainers to review important maintenance/stability contributions. > > As a contributor (non-committer + non-maintainer), I don’t have any issue > with the PR limit. I cannot imagine the current status quo is sustainable > from a maintainer’s perspective, and yet somehow you all have remained by > far the most responsive and thorough maintainers of any open source project > I’ve worked on. To me it seems like PR limits are the least gate-keeping, > most practical solution. > > On Wed, Sep 23, 2026 at 6:39 AM Jarek Potiuk <[email protected]> wrote: > > > For now - it looks like we are heading towards consensus, and 5 is the > most > > popular choice. > > > > On Tue, Sep 22, 2026 at 12:15 PM Jarek Potiuk <[email protected]> wrote: > > > > > > You can still create the branches in your fork, you just can’t hit > the > > > “create PR” button yet. > > > > > > And when we implement "CI in your fork" - you will even get CI run on > > that > > > branch. > > > > > > On Tue, Sep 22, 2026 at 12:11 PM Ash Berlin-Taylor <[email protected]> > > wrote: > > > > > >> I would say +1 to this at a limit of 5. > > >> > > >> Yes, that might affect one or two contributors, but as Christos said, > > the > > >> current bottle neck is getting PRs reviewed and merged, so opening > more > > PRs > > >> doesn’t really do anything to help you get things merged quicker. > > >> > > >> You can still create the branches in your fork, you just can’t hit the > > >> “create PR” button yet. > > >> > > >> And then once the .asf.yaml exclude lands then each contributor could > > >> make a case of why they should be added to the cap bypass list. > > >> > > >> -ash > > >> > > >> > On 22 Sep 2026, at 08:49, Jarek Potiuk <[email protected]> wrote: > > >> > > > >> >> GitHub already has a bypass list for the cap, so I opened a draft > in > > >> >> infrastructure-asfyaml to make it configurable: > > >> >> github.com/apache/infrastructure-asfyaml/pull/135 > > >> > > > >> > COOL! I ran it through my "sandbox-test" SKILL and it looks great - > > all > > >> > checks out, and all edge cases pass. There is only one nit: checking > > if > > >> the > > >> > login is a GitHub account. One unknown login discards the whole > batch, > > >> so > > >> > it would be worth checking the logins before calling the API. > Comment > > >> > posted: > > >> > > > >> > > > https://github.com/apache/infrastructure-asfyaml/pull/135#issuecomment-5772952423 > > >> > > > >> > J. > > >> > > > >> > > > >> > On Tue, Sep 22, 2026 at 9:14 AM Andrew Chang <[email protected] > > > > >> wrote: > > >> > > > >> >> Thanks Jarek. I agree that trust should come with responsibility. > > >> >> > > >> >> I looked into collaborators' role. Seems like they only get triage, > > not > > >> >> write access, so the cap still applies to them. > > >> >> And the collaborators list has a hard limit of 10 per repo (ASF > > >> policy), > > >> >> which Airflow already uses up. Still, I think reusing collaborators > > is > > >> a > > >> >> good starting point. > > >> >> > > >> >> GitHub already has a bypass list for the cap, so I opened a draft > in > > >> >> infrastructure-asfyaml to make it configurable: > > >> >> github.com/apache/infrastructure-asfyaml/pull/135 > > >> >> > > >> >> Or we could simply sync the bypass list with the collaborators list > > >> >> automatically. It would be easier to maintain, though the > > collaborators > > >> >> list would then need to be revisited more often. > > >> >> > > >> >> This could be a way to recognise people who review and help others. > > >> >> Not sure this is the right direction, but wanted to have something > > >> concrete > > >> >> to look at. Looking forward to hearing your thoughts. > > >> >> > > >> >> Thanks, > > >> >> Andrew > > >> >> > > >> >> Yuseok Jo <[email protected]> 於 2026年9月22日週二 下午2:25寫道： > > >> >> > > >> >>> Hello, > > >> >>> > > >> >>> Thanks Jarek for initiating this discussion with clear data. > > >> >>> > > >> >>> Even as a non-committer, seeing over 1,000 open PRs made it > obvious > > >> how > > >> >>> tough it must be for maintainers to keep up with the queue. I > agree > > >> that > > >> >>> addressing this review bottleneck is a timely and necessary step. > > >> >>> > > >> >>> Since much of the current count reflects existing PRs that have > > >> >> accumulated > > >> >>> due to review delays, starting with a cap of 7 or 10 should > already > > be > > >> >>> quite effective at stopping rapid new growth and clearing the top > > >> heavy > > >> >>> backlog. I'd like to suggest starting there as an initial step, > and > > >> then > > >> >>> re-evaluating the numbers as the queue drains to see if moving > > toward > > >> a > > >> >>> stricter limit like 5 makes sense for a smooth transition. > > >> >>> > > >> >>> Thanks for driving this effort. > > >> >>> > > >> >>> Thanks, > > >> >>> Yuseok > > >> >>> > > >> >>> On Tue, Sep 22, 2026 at 6:50 AM Christos Bisias < > > >> [email protected]> > > >> >>> wrote: > > >> >>> > > >> >>>> Hello, > > >> >>>> > > >> >>>> Currently there are 1024 open PRs which is crazy. Anything beyond > > 200 > > >> >>> isn’t > > >> >>>> manageable. > > >> >>>> > > >> >>>> I think 5 is a very reasonable limit. Based on the number of open > > PRs > > >> >> we > > >> >>>> shouldn’t be arguing over a higher number until the situation > > >> improves. > > >> >>>> > > >> >>>> There is no point in having 10 open PRs if no one has the time to > > >> >> review > > >> >>>> them. The longer it takes to get some feedback, the more time you > > >> have > > >> >> to > > >> >>>> move on to another issue and then open another PR which will then > > >> lead > > >> >> to > > >> >>>> even further delay for a review. Hopefully with a more strict > > limit, > > >> >>>> contributors will go for quality over quantity. > > >> >>>> The only problematic situation I can think of, is when someone > has > > >> >>> reached > > >> >>>> the limit but needs to open a PR for an urgent fix for a bug, a > > >> >> security > > >> >>>> issue, a flaky test, etc. Github allows for a whitelist with > users > > >> >> exempt > > >> >>>> from the limit. I think in that case, maintainers could > temporarily > > >> add > > >> >>> the > > >> >>>> user to the list. > > >> >>>> > > >> >>>> +1 for 5 > > >> >>>> > > >> >>>> Thanks, > > >> >>>> Christos > > >> >>>> > > >> >>>> > > >> >>>> On Mon, 21 Sep 2026 at 22:51 Andrew Chang <[email protected] > > > > >> >> wrote: > > >> >>>> > > >> >>>>> Thanks for pushing all of this, +1 on 7. > > >> >>>>> > > >> >>>>> To be clear, I am one of the group A contributors on Jarek's > list, > > >> >> so I > > >> >>>> am > > >> >>>>> not a neutral party here. > > >> >>>>> Personally I would prefer a higher cap like 10... but I agree > with > > >> >>>> Jarek's > > >> >>>>> and Vincent's point that reviewing and helping others is what > > >> Airflow > > >> >>>> needs > > >> >>>>> most right now. > > >> >>>>> > > >> >>>>> I ran some numbers for group A. Since drafts PR now count, here > is > > >> >>> what a > > >> >>>>> cap of 7 means for the 9 people in that group: > > >> >>>>> ("typical / busy" = open PRs at p50 / p90 over the days they had > > any > > >> >> PR > > >> >>>>> open; "over 7" = share of those days above 7): > > >> >>>>> > > >> >>>>> - SameerMesiah97: typical 7, busy 10, over 7 on 43% of days > > >> >>>>> - shivaam: typical 4, busy 7, over 7 on 9% > > >> >>>>> - Vamsi-klu: typical 6, busy 13, over 7 on 45% > > >> >>>>> - Andrushika: typical 7, busy 11, over 7 on 48% > > >> >>>>> - yuseok89: typical 4, busy 10, over 7 on 18% > > >> >>>>> - steveahnahn: typical 2, busy 10, over 7 on 20% > > >> >>>>> - ColtenOuO: typical 5, busy 25, over 7 on 40% > > >> >>>>> - stephen-bracken: typical 1, busy 6, over 7 on 1% > > >> >>>>> - fat-catTW: typical 5, busy 17, over 7 on 42% > > >> >>>>> > > >> >>>>> With a cap of 7, about half of the group would be at or above > the > > >> >> limit > > >> >>>> on > > >> >>>>> roughly 4 days in 10. > > >> >>>>> I am not raising this to argue for a higher number; completely > > fine > > >> >>>>> starting at 7 for the reason above. Just want it on record, so > > that > > >> >> if > > >> >>> we > > >> >>>>> revisit the number later we have a baseline. > > >> >>>>> > > >> >>>>> On a related note, I like Henry's trust list idea (the bypass > list > > >> >>> Damian > > >> >>>>> mentioned). > > >> >>>>> The numbers above show that the number of good contributors (I > > >> assume > > >> >>>> that > > >> >>>>> is group A mentioned above) that would need it is small, so the > > >> >> bypass > > >> >>>> list > > >> >>>>> should be easy to maintain. > > >> >>>>> If we agree it is the right direction, I can look into the > > .asf.yaml > > >> >>>> side. > > >> >>>>> > > >> >>>>> > > >> >>>>> Thanks, > > >> >>>>> Andrew > > >> >>>>> > > >> >>>> > > >> >>> > > >> >> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > >
