Ros2-gbp release repository permissions are now managed via GitHub repository

nuclearsandwich · 2022-02-09T00:59:06.497Z

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.

Kenji_Brameld · 2022-02-11T00:17:21.092Z

@nuclearsandwich Thanks for this work!
How should we name release teams if a repository is not maintained by an organization? There are multiple repositories in rolling/distribution.yaml that are currently maintained by individual Github users.
Perhaps the team name can be the individual’s name or the repository name?

nuclearsandwich · 2022-02-11T01:21:17.598Z

My default convention has been to use the repository where there isn’t a larger group of repositories. vision_msgs.tf is one example.

If you (or anyone) would prefer that the repositories they currently maintain are kept under a single team named after yourself that’s fine with me! We can always re-organize if a repository gets handed off to a new maintainer.