request a maintainer access

[wep21]

I would like to address #18, so I need a maintainer access to this repository.

[SteveMacenski]

The current maintainers can run releases (#18) when we are able to from having the dependencies met in a sustainable way. I'm certainly not interested in being a blocking force, but I would like to understand your use of open3D, perception_open3d, and knowledge of those codebases before handing keys over to someone else. With maintainer rights and especially release rights, someone can do alot of damage, much of which is irreversible. Have you gone through that process before and aware of the ROS release and stability policies?

This work is broadly from @nkhedekar so he should also have a say in it as the primary maintainer (I'm really just here to keep the wheels greased).

[nuclearsandwich]

Have you gone through that process before and aware of the ROS release and stability policies?

I'm following a reference from another issue here so this is a bit of a drive-by comment with no expectation that it needs to be acknowledged in any way.

I've worked with @wep21 on a fair number of recent release interactions and have found them to be diligent, communicative, and positive in all our interactions. I can't "endorse" or recommend them beyond that.

[SteveMacenski]

ros/rosdistro#33445
ros/rosdistro#33447

Releases made!

@wep21 if you'd like maintainer rights, I'd be fine with that as long as major things (releases / extremely large changes) have the approval or discussion from either me or @nkhedekar

[wep21]

@SteveMacenski Thank you for creating releases.

if you'd like maintainer rights, I'd be fine with that as long as major things (releases / extremely large changes) have the approval or discussion from either me or @nkhedekar

Of course, I would like to discuss the major things with you. Also, I would like to move the release repository for ros2 to ros2-gbp as I mentioned in ros2-gbp/ros2-gbp-github-org#57 if you're okay with it.
Can I reopen the pull request? cc @nuclearsandwich

[SteveMacenski]

It is already in a gbp organization https://github.com/ros-gbp/perception_open3d-release there's no real value in having it be in either or. That pull request should remain closed, as far as I know, that repository has nothing to do with the release process for maintainers to create binaries for ROS 2. I'm not exactly sure what that repo is for, but I don't think we need to make any changes there (or if someone else for some reason; those maintainers handle it themselves)

[nuclearsandwich]

It is already in a gbp organization https://github.com/ros-gbp/perception_open3d-release there's no real value in having it be in either or.

For ROS 2 distributions post-Foxy there is a strong recommendation to host the release repository in ros2-gbp.
For Rolling it is all-but required(+) as that is the only organization that the migration tools target when pushing automated re-blooming for new platforms or new distributions from Rolling.

+ Making it required is largely a matter of me having the time to update the review guidelines and the language in the docs: https://docs.ros.org/en/ros2_documentation/humble/How-To-Guides/Releasing-a-ROS-2-package-with-bloom.html#minor-differences-from-ros-1-bloom

I'm not exactly sure what that repo is for, but I don't think we need to make any changes there (or if someone else for some reason; those maintainers handle it themselves)

The repository there is the "back end" infrastructure for managing repository settings and permissions in the ros2-gbp organization on GitHub. Here's the discourse post announcing the changes to permissions there and the follow-up post introducing the repository once we made it open source.

that repository has nothing to do with the release process for maintainers to create binaries for ROS 2

When creating new packages (repositories, really) for ROS 2 I recommend using that repository to request a release repository in the ros2-gbp organization. When Rolling is updated using the migration tool the new release information will be hosted there unconditionally so it makes sense to set up new release repositories there from the outset.

[SteveMacenski]

@nuclearsandwich if you give me access to ros2-gbp, I'll move it over (I'm surprised I don't have it). I can't create new public repos to transfer it over even though I'm a member and have the ros-gbp rights. Irregardless of this repo, I need to be able to make new release repositories in the ROS 2 version apparently and I bet there's a few other projects I should migrate over as well

[tfoote]

@SteveMacenski The organization is maintained by automation. Manual changes like adding new repositories will be reverted on the next update. Please open the PR on https://github.com/ros2-gbp/ros2-gbp-github-org to create the appropriate repositories with maintainer teams. You can choose to push the old repository there but we generally don't worry about migrating old release repositories and just leave previous ones on place for consistency. Reopening ros2-gbp/ros2-gbp-github-org#57 is likely going to provide the access necessary and one or more of the current maintainer team would sign off on the changes in that PR as well giving @wep21 access too.

[SteveMacenski]

I'm debating keeping everything in ros-gbp then, there's already alot of process involved in releasing a package and on rolling I end up releasing updates correspondingly to a new distribution fork because we haven't kept up at the application and utility level with releasing Rolling updates on any regular cadence (so updates are required on a new distribution sync anyway to get all the changes).

Creating a central registry to releasing new packages makes sense for lower-level packages that receive regular / frequent rolling updates anyway so that new bloom runs are automated for new distributions, but doesn't make a whole lot of sense for infrequent rolling release updates or utility/application level software - we have to do it anyway so that the newest stuff is reflected in rolling pre-distribution fork. For our uses of releasing, I this just adds another barrier to entry for releasing new software in the future and I'm not sure its worth it. I lean towards just stick with ros-gbp and keep this stuff a little more federated.

My concern here is that this technology stack for this centralized approach is going to continue to evolve / change and I'm not going to keep up to date with it and find out later that things have changed only when things aren't working the way I expect right before a distribution fork. Ideally, I'm not looking to create additional maintainer overhead on myself or specialized requirements that 'some' repositories require 'this' and 'others' require 'that', if that makes sense.

Are there changes here planned in the foreseeable future or anything in particular I need to know about this moving forward? I have other packages here (navigation2-release radar_msgs-release ros2_ouster_drivers-release etc) that didn't have this overhead when I created them. If this is the extent of the master plan (just a central registry for 1-time initialization) I think that's fine. I'd just like to understand if there's more coming that I need to be aware of to make the final call.