I'm happy to be dropped for now while I focus on other things!

I'm happy to be dropped for now while I focus on other things!

Thank you so much for all the work that you've done causing this transition to be effective.

I removed @infinisil and added @MattSturgeon.

Still waiting on feedback from @azuwis and @winterqt before I make changes for them.

I'm currently busy with other things, please drop me for now.

I appreciate the thought, but I am also quite busy right now; please remove me from consideration for the time being.

Thanks for the feedback, did so!

Request for team creation is here: NixOS/org#128

Having a team in principle sounds ok. I am only a bit concerned that the list of people is currently a bit small. zowoq hasn't reacted on this and I am also quite busy. Could we for transition maybe allow all committers to bypass CI until we gained more confidence with the process and we have a bigger pool? In principle I like to think, I trust people enough that can potentially make my system unbootable, would also be considered enough to think twice before hitting a red "Bypass required checks" button. I think if we catch someone abusing this, we probably should rethink their commit rights in the first place.

zowoq hasn't reacted on this

They have, actually.

I am only a bit concerned that the list of people is currently a bit small.

I don't see a small team as an intrinsic problem, it shouldn't dictate who actually reviews CI-related changes; anyone is welcome to. Rather it should describe who is interested in the subject.¹

If the number of interested parties is a problem, then it's still a problem without a team, just a less visible one 😉

I'd argue having a team is the first step in encouraging new people to join it.

Could we for transition maybe allow all committers to bypass CI until we gained more confidence with the process and we have a bigger pool?

I think this discussion will be more relevant when we actually start discussing/implementing rulesets that require status checks. Until then, the CI team is no different from any other nixpkgs team.

That said, this is an example of where team size could become a practical issue; if the team were the only ones with bypass permission and it turned out bypasses were needed too often for the team to keep up with.

I assume some other teams would also get bypass permission, e.g. the security team and org owners? Maybe it'd be treated similarly to commit bit, and the committer delegation team could also decide who gets the additional "bypass bit"?

Whether or not enough active committers can bypass would be something we'd have to continually review.

think twice before hitting a red "Bypass required checks" button. I think if we catch someone abusing this, we probably should rethink their commit rights in the first place.

100%, any bypass should always be for exceptional circumstances, or for implementing a change to CI that fails the old CI. The former should be done extremely rarely and with a lot of consideration. The latter should never affect the actual NixOS or nixpkgs outputs consumed by end-users, only the CI workflows.

Okay. My worry above was mainly about who is able to bypass, not the team as such (and not blocking this PR). Since the GitHub ci is just the forefront to hydra, I don't think we need to be overly stingy with this privilege. I also think we shouldn't necessarily bottleneck other groups with unrelated tasks.

Since the GitHub ci is just the forefront to hydra, I don't think we need to be overly stingy with this privilege.

Ah gotcha. That makes sense.

We could allow any committer to bypass, which would match the status quo while making the act of ignoring CI much more explicit.

Alternatively, the committer delegation team could grant a "bypass bit" separately. But as you say, this could be granted to a significant portion of committers, perhaps even anyone who's been a committer longer than X weeks?

Assuming it isn't easy to accidentally bypass, then I'm fine with either approach. If bypassing accidentally was easy, it'd kinda defeat the point of having a ruleset in the first place; that's why I was initially assuming most committers wouldn't have bypass bit.

The question about bypassing branch protection rules is important - but imho not the right place here. I created NixOS/org#130 to discuss this, let's move all of that discussion there.

The team creation is independent of how we end up setting up those rules.

I think the key takeaway from this PR is transparency and visibility. Instead of ~10 review requests, there will now be at most 5 review requests for CI related changes - and it's much clearer from whom to expect feedback now. That's important.

And having a CI team in place will hopefully also help to encourage people to show interest and join the effort, I agree with that @MattSturgeon.

Successfully created backport PR for release-25.05:

• [Backport release-25.05] teams/ci: init #418417