Baxter release permissions

[k-okada]

Can someone give me permission to baxter GitHub repository for releasing into the kinetic?
Or since RethinkRobotics is no longer exists, can we copy to some other places? Is this the special case of Releasing repositories form "other" people ?

[knorth55]

I think @IanTheEngineer did maintenance for baxter amd sawyer.

[knorth55]

Indigo is EOL, and we want to release Baxter packages in Kinetic.
Every package related to Baxter got stacked now.

[knorth55]

Any update for this topic?
We are waiting for response.

[knorth55]

any update for this topic?
we are waiting for response about this topic.
for melodic users, we need one of these PRs for baxter_simulator to build correctly.

Use of auto to prevent collisions between std and boost shared pointers in Kinematics

Fix compilation on Ubuntu 18.04 w ROS Melodic

[tfoote]

Since it seems that there’s no response from the upstream maintainers or ability to do a maintainer transition I think that this would be a reasonable to transition maintainership.

Since we don’t have access to the source please go ahead and just fork it and then we can authorize you to make the releases into the distro from the fork(s).

[knorth55]

@tfoote Thank you so much for your response.

@k-okada Do you have any idea? ros-orphaned package is good, I think, but what do you think?

[k-okada]

Ok, I will create ‘ros-orphaned’ ‘ros-orphaned-gbp’ organization, fork, and release them, as a ROS Orphaned Package Maintainers initiative. (http://wiki.ros.org/OrphanedPackage, https://github.com/ros-infrastructure/rep/pull/150)

But this means if someone willing to maintain the repository, we will move the package to them and I understand there is a concern of confusion.

Regarding the location of “orphaned” repositories: I don’t think moving them around when the maintainer status changes (which could happen multiple times over time) is beneficial.

So another option is to fork to ‘ros’ and ‘ros-gbp’ and I’ll take care of them. How do you think ?? @tfoote @dirk-thomas

Releasing repositories form "other" people

Please see the REPs 127 / 140 which already describe something like such a “QA group”. You can use the following maintainer information in the package manifest: name: Unmaintained see http://wiki.ros.org/MaintenanceGuide#Claiming_Maintainership email: ros-orphaned-packages@googlegroups.com If you release a package with this information you should subscribe to that Google group and act on future notification emails for the packages. Otherwise it will be the same problem that nobody gets not…

[tfoote]

I think going ahead with the ros-orphaned organizations makes sense for this case since we don’t have access to the existing one to make a graceful handoff. If someone wants to take up maintainership it should be transferred out. If there’s possible handoff of the maintainership we should still try to avoid moving them though. Github is good at redirects for a while, but it isn’t guarenteed to continue to work and there are likely a lot of links that will be dangling.