On Wed, Jun 3, 2026 at 12:57 PM Andres Freund <[email protected]> wrote: > On 2026-06-03 11:12:43 -0700, Jacob Champion wrote: > > Are we certain that GitHub isn't going to opt them all into > > test-every-stable-commit-and-PR on their next sync? > > It'd not test every stable commit, just the ones separately pushed, no?
Ah. Slightly embarrassing: I misunderstood the Sync Fork functionality in GitHub, which I'd never actually used. It's a one-time synchronization, not a permanent "keep this up to date" toggle, so the situation's not as alarmingly carbon-intensive as I made it sound. So yes, just every push. I don't know if the Sync Fork button acts as a push trigger as well. > > I guess I'll pipe up again to mention that we have a lot of downstream > > forks. > > I'm not entirely unconcerned, but I think requiring explicit per-repo > configuration in a postgres specific way will cause more harm long term What kind of harm are we talking about -- just that they have to follow the steps that our hypothetical skip logic prints out, or else ask on the list? > than > some folks having to figure out how to disable the workflow. A vanishingly small percentage of our 5,700 forks have to sync up with us in order to permanently outnumber the people who will ever test PRs on purpose, I think. Concretely: I propose that we bail out of the setup step if the repository isn't postgres/postgres, just for the initial committed version, and then we can test what this actually does in practice to our downstream forks. If I'm being overly paranoid, we can immediately remove it; else we can add an opt-in. But adding it after the fact won't protect anyone who synced up in the interim. --Jacob
