Upcoming changes to ros2-gbp organization

In order to improve administration of the ros2-gbp organization on GitHub we are going to be deploying some changes that may temporarily affect push permissions to repositories in that organization for repository maintainers.

Starting around 2021-08-18T22:00:00Z I’ll start running a script which will begin sending membership invitations to the ros2-gbp organization for many individuals who currently have push access to release repositories within ros2-gbp via “outside collaborator” status on individual repositories.

Please accept the invitations when you receive them to retain push access to the associated repositories.

If you have been invited to a team that grants access to repositories that you do not believe you should have push access to or you have not been invited to a team which maintains repositories you require access to please contact me via Discourse direct message so I can review the situation and update the permissions appropriately.

Unless there are problems with the team invitation rollout, I will start removing the now-redundant direct outside collaborator permissions on some repositories in the ros2-gbp organization on 2021-08-19T07:00:00Z.


It took some time to run but teams have all been created and invitations have all been sent.

What was your main motivation for making this change?

The fact that outside-collaborators cannot be assigned to teams?

1 Like

There were a number of complimentary factors. Switching to team-based permissions rather than direct collaborators makes ongoing auditing and maintenance easier. And we’ve increased the burden for ourselves by specifying that release repositories for ROS 2 distributions should be in the ros2-gbp organization to facilitate the migration tools used by the rolling release process.

GitHub’s interface has made strides but it is considerably more difficult to audit outside collaborators rather than teams when reviewing permissions across an organization. Teams also make it easier to group collections of individuals and repositories together rather than managing each repository and maintainer combination independently.

Behind the scenes of this migration is a transition to using Terraform and the Terraform GitHub provider to model repository permissions in the ros2-gbp organization using a declarative description language similar to our chef and puppet scripts for the build farm deployment and in fact the infrastructure beneath our build farms is also managed by Terraform although that aspect is not currently open source due to being closely tied with our own deployment within AWS.

My personal hope is that after some internal review we can make the ros2-gbp permissions repository public and allow requests for permissions changes to come in the form of pull requests against the configuration directly. It’s also been proposed that the rosdistro distribution.yaml or package.xml manifest files could be updated to provide enough information to automatically generate Terraform configurations granting maintainers the correct repository permissions although that’s not something that we’ve dug deep into or committed to.