You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Request for Python buildbot-owners bulk membership update #608
Similarly, I will also be removing folks who no longer operate a current worker, with many thanks to all for in most cases providing and/or administrating the only worker(s) for a platform for years at a time (and if anyone ever wants to host a new worker, please don't hesitate to reach out :)):
Hmm, are you sure? The group has write access to this repository.
Nothing against the fine people mentioned here, but in general, anyone should be able to add a worker; shouldn't changing the config repo require some more trust?
With my worker owner hat on, I like having access to adjust the config on my own workers, and with my buildbot admin hat on I like owners being able to time both sides of updates to their own stuff to avoid downtime. Realistically, the buildmaster config is relatively low stakes and relatively recoverable in case of accidental damage, and I'm comfortable with worker owners having write there. It might be a good idea to require review from an admin (buildbot-config group), though?
Sidenote: I also just realized in looking into this that python-core only had read while python-triage had triage on buildmaster-config, so I bumped python-core up to triage.
Hmm not sure if it's a good idea to have write access honestly. We are talking about the buildmaster-config repo, right?
The buildbot infra config AND each workers/builders configs live there.
Obviously a worker owner shouldn't meddle with the infra design config.
Now let's say I wanna fix up the parallel processes for my workers, I think that would be reasonable to do it myself. But e.g. enabling --with-dtrace and we start getting failures (as it happened), I will be able to block the CPython releases that rely on stable buildbots.
Activity
koobs commentedon Sep 28, 2026
Here @zware 👋 if you need more FreeBSD builders, I have spare VM's (arm64 / amd64 ) I can provision on
encukou commentedon Sep 28, 2026
Hmm, are you sure? The group has write access to this repository.
Nothing against the fine people mentioned here, but in general, anyone should be able to add a worker; shouldn't changing the config repo require some more trust?
hugovk commentedon Sep 28, 2026
We have three buildbot teams:
"Buildbot owners" + "People who own workers for buildbot.python.org" matches @zware's updates, but perhaps that team doesn't need write for https://github.com/python/buildmaster-config, only the config team does?
zware commentedon Sep 28, 2026
With my worker owner hat on, I like having access to adjust the config on my own workers, and with my buildbot admin hat on I like owners being able to time both sides of updates to their own stuff to avoid downtime. Realistically, the buildmaster config is relatively low stakes and relatively recoverable in case of accidental damage, and I'm comfortable with worker owners having write there. It might be a good idea to require review from an admin (
buildbot-configgroup), though?Sidenote: I also just realized in looking into this that
python-coreonly hadreadwhilepython-triagehadtriageonbuildmaster-config, so I bumpedpython-coreup totriage.stratakis commentedon Sep 28, 2026
Hmm not sure if it's a good idea to have write access honestly. We are talking about the buildmaster-config repo, right?
The buildbot infra config AND each workers/builders configs live there.
Obviously a worker owner shouldn't meddle with the infra design config.
Now let's say I wanna fix up the parallel processes for my workers, I think that would be reasonable to do it myself. But e.g. enabling --with-dtrace and we start getting failures (as it happened), I will be able to block the CPython releases that rely on stable buildbots.