Following up from the changes to the ros2-gbp organization permissions I’ve just made the Terraform scripts that we use to manage the organization public along with a couple of issue templates which will hopefully streamline the process of requesting and receiving access to release repositories within the ros2-gbp organization on GitHub.
You can see the repository for yourself here: https://github.com/ros2-gbp/ros2-gbp-github-org
Access to release repositories is granted on the basis of a “release team”. Each team consists of zero or more GitHub users, each of whom can be members of multiple release teams, as well as one or more release repositories, each of which can be managed by multiple release teams.
I set up most release teams based on who has been a contributor to each release repository in the past as well as when fielding requests from specific individuals who have been my de facto “alpha testers” of this process.
Requests for changes can be made either as issues or pull requests depending on your interest in engaging with the terraform scripts yourself. We’ve been using terraform for various internal infrastructure projects for some time now and I’ve found the declarative format approachable but it’s absolutely not a requirement that you modify terraform scripts yourself to make changes. My hope is that the individual release team files are plain enough to serve as “executable documentation” of the organization maintainership. @tfoote has also suggested that we could in the future generate some of this information directly from package.xml maintainer fields as well so manually writing terraform scripts is not a requirement now nor is it guaranteed to be the method for changes.
It’s no coincidence that we’ve gotten this ready just as we are migrating ROS 2 Rolling to Ubuntu Jammy this migration will pull a number of new release repositories into the ros2-gbp organization which is likely to put increased load on the process of fielding requests for which there was previous no dedicated channel.