move release repository from jbohren to tork-a

[k-okada]

• ros-indigo-xdot is overriden by adding xdot to rosdep. #4978 (comment),
• So if we want to continue using smach_viwer, we have to switch to system xdot or find other means.
• ros-indigo-xdot and system xdot is very different, my solution is to copy ros-indigo-xdot within smach_viewer directory copy xdot from https://github.com/jbohren/xdot, ros-visualization/executive_smach_visualization#14
• seems original maintainer is so busy, we haven't released this more than a year smach_viewer on Kinetic ros-visualization/executive_smach_visualization#13 request for release into jade jbohren/executive_smach_visualization-release#1

I understand receiving maintainer jobs is too much responsibility for everyone, but for releasing existing software is not a big deal and I think there might be good way not to drop existing software just because we have new ros distro.

• [bloom release maintainer level] packages already prepared (already ran catkin_prepare_release) and just forget to run bloom-release, specially for new distro => put release repo to community level organization (ex. https://github.com/ros-gbp/) give access to everyone who asked for release. If one have familiar with Ubuntu and Github, they can run bloom-release. Ex. usb_cam: 0.3.4-0 in 'kinetic/distribution.yaml' [bloom] #14862 (usb_cam), libuvc_ros: 0.0.7-0 in 'kinetic/distribution.yaml' [bloom] #14867 (libuvc_ros), camera_umd: 0.2.4-0 in 'kinetic/distribution.yaml' [bloom] #14870 (camera_umd)t

• [package release maintainer level] packages is ready to run catkin_prepare_release, but maintainers did not run catkin_prepare_release, not sure why this happens, may be maintainer merged, but forget to run catkin_prepare_release before they stop maintain it. Currently if original maintainer stop maintaining , we have to send mail / issue many times for transfer or add access to that repository (this is time consuming) or we have to force take over it (this confuse users, which we should look into ?). So if we should control this type of software under community level control and give access to everyone who have familiar with catkin_prepare_release. Ex gscam: 0.2.0-0 in 'indigo/distribution.yaml' [bloom] #14878 (gscam),

• [package migration maintainer level] packages need to be fixed before run catkin_prepare_release. You do not have to have algorithm level knowledge or think about software design, mostly just to fix migration level, such as opencv2 -> opencv3 or qt4 -> qt5. So not as heavy as full-software level maintainer. May be potential solution is equal to package release maintainer level situation. Ex. move release repository from jbohren to tork-a #14890 (smach_viewer)

[k-okada]

requested on jbohren/executive_smach_visualization-release#1, ros-visualization/executive_smach_visualization#13

[dirk-thomas]

Please see https://discourse.ros.org/t/releasing-repositories-form-other-people/1797 for a discussion about this.

[dirk-thomas]

Please see the conclusion: https://discourse.ros.org/t/releasing-repositories-form-other-people/1797/10

[k-okada]

• camera_umd
  • update maintaner tag for ros-orphaned-packages Add ROS Orphaned Package Maintainers to maintainer tag ros-drivers/camera_umd#18, camera_umd: 0.2.4-0 in 'kinetic/distribution.yaml' [bloom] #14870
  • write access to release repository
  • release into kinetic camera_umd: 0.2.5-0 in 'kinetic/distribution.yaml' [bloom] #15236
• libuvc
  • write access to release repository
  • release into kinetic libuvc: 0.0.5-2 in 'kinetic/distribution.yaml' [bloom] #14984
• libuvc_ros
  • update maintaner tag for ros-orphaned-packages add ROS Orphaned Package Maintainers to maintainer tag ros-drivers/libuvc_ros#40, libuvc_ros: 0.0.7-0 in 'kinetic/distribution.yaml' [bloom] #14867
  • write access to release repository
  • release into kinetic libuvc_ros: 0.0.8-0 in 'kinetic/distribution.yaml' [bloom] #15233
• usb_cam
  • update maintaner tag for ros-orphaned-packages add ROS Orphaned Package Maintainers to maintainer tag ros-drivers/usb_cam#69 usb_cam: 0.3.4-0 in 'kinetic/distribution.yaml' [bloom] #14862
  • release new version
  • write access to release repository
  • release into kinetic usb_cam: 0.3.5-0 in 'kinetic/distribution.yaml' [bloom] #15225
• gscam
  • update maintaner tag for ros-orphaned-packages add ROS Orphaned Package Maintainers to maintainer tag ros-drivers/gscam#35, gscam: 0.2.0-0 in 'kinetic/distribution.yaml' [bloom] #14880
  • write access to release repository
  • release into kinetic
• executive_smach_visualization
  • update maintaner tag for ros-orphaned-packages add ROS Orphaned Package Maintainers to maintainer tag ros-visualization/executive_smach_visualization#15, executive_smach_visualization: 2.1.0-0 in 'kinetic/distribution.yaml' [bloom] #14888
  • write access to release repository
  • release into kinetic executive_smach_visualization: 2.0.1-0 in 'kinetic/distribution.yaml' [bloom] #15288
• executive_smach_tutorials
  • update maintaner tag for ros-orphaned-packages executive_smach_tutorials: 0.1.0-0 in 'indigo/distribution.yaml' [bloom] #14873
  • write access to release repository
  • release into kinetic

[dirk-thomas]

@k-okada What is the status on this? If it needs to be tracked for longer I would rather have you move this into a ticket since it shouldn't be a PR anymore.

[k-okada]

@dirk-thomas I have almost done this project so we can close now, thank you for your continuous support.

• can we move https://github.com/jbohren/executive_smach_visualization-release to ros-gbp or somewhere? I think we'll want to move release repo on @jbohren personal repo to somewhere in future.
• can we create shared_autonomy_manipulation-release to ros-gbp organization? add 'ROS Orphaned Package Maintainers' as maintainer SharedAutonomyToolkit/shared_autonomy_manipulation#6 (comment) , This up to you, we have option to host release repo on SharedAutonomyToolkit organization

BTW, I' very sorry to ask you for moving the unmaintained package from personal repo to ros/osrf organization again and again. If you do not mind, that's ok. But if this kills your time, we can create new organizatino and put admin acess to team of unmaintained organization (currently only me ....)
https://discourse.ros.org/t/releasing-repositories-form-other-people/1797/11?u=k-okada

if we can get answer but find original maintainer lose attention. ask for package transfer to ex. ros-unmaintained organization
if we can not get response, fork that package and gbp to ros-unmaintained organization

[dirk-thomas]

@k-okada Please try to not only mention a single person on requests like this. The chances for me missing one of those especially when a ticket gets closed is > 0. You can e.g. create a ticket in ros/rosdistro for such requests. That will give it bigger visibility and therefore a faster response.

can we move https://github.com/jbohren/executive_smach_visualization-release to ros-gbp or somewhere? I think we'll want to move release repo on @jbohren personal repo to somewhere in future.

That sounds good to me. But it has to be initiated by a user owning the current repo (which also has access to the destination).

can we create shared_autonomy_manipulation-release to ros-gbp organization? SharedAutonomyToolkit/shared_autonomy_manipulation#6 (comment) , This up to you, we have option to host release repo on SharedAutonomyToolkit organization

I have created https://github.com/ros-gbp/shared_autonomy_manipulation-release and added you as a collaborator with admin access. So you can delegate further access.

[k-okada]

@dirk-thomas thank you , but i'm afraid we need something to activate the release repo, I can not push and even fork the repo. I'm not sure what the problem was, need a initial commit from admin?

[k-okada]

@dirk-thomas sorry, It's my fault. I need to accept invitation link ... everything is ok now