Proposal to split rqt_common_plugins and rqt_robot_plugins

[Dirk Thomas]

Currently the `rqt_common_plugins` repository contains 20+ rqt plugins, `rqt_robot_plugins` contains 10+. Since many of the plugins are pretty stable with very few changes over time that leads to many unnecessary releases (due to changes in a few plugins in the repo which should be released, e.g. https://github.com/ros-visualization/rqt_common_plugins/blob/master/rqt_action/CHANGELOG.rst). Additionally the question has come up frequently to add even more plugins to the repo.

From a maintenance point of view I try to avoid adding even more since it boils down to me having to take care of all the plugins myself. Therefore I am considering to split these plugins into separate repositories. While increasing the number of repos it allows each repo to be maintained by a distinct person (or multiple) which can release that package at their own discretion.

The effort to release the packages into a new distro is slightly higher (running bloom N times instead of once, but each invocation is also significantly faster). On the other hand any follow up release is much less work, and publishes less uselessly updated Debian packages.

It additionally makes it easier to distribute the maintenance. New plugins can be added to the metapackages easily and all plugins are treated the same. Currently users expect the plugins in these repos to be "special" and don't consider "external" rqt plugins. We can still encourage developers to put their plugins into the `ros-visualization` org unit and give them full admin access to these repos. I would encourage maintainers to move their existing plugins into that org unit since it gives confidence to the users that the plugin will be available in the future since it is easier to pass maintainership if the original author decides to move on.

Both repos only have a `master` branch which serves all active ROS distros. So updating all rosdistros after the splitting should be straight forward (remove the existing entries for the obsolete repos, add new entries for the new repos). From a Debian package point of view the transition will be transparent to the user.

What do you think about this?

Thanks,

- Dirk

[dorian.o...@gmail.com]

I think your proposal makes a lot of sense.
Together with a well advertised place where developers can make their plug-ins know, like the ros wiki, this would hopefully lead to more usage of "unofficial" plug-ins and more developers working on plug-ins in general.

Cheers
Dorian

[Isaac Isao Saito]

+1. Thanks for all the maintenance!

> Currently users expect the plugins in these repos to be "special" and don't consider "external" rqt plugins. We can still encourage developers to put their plugins into the `ros-visualization` org unit and give them full admin access to these repos. I would encourage maintainers to move their existing plugins into that org unit since it gives confidence to the users that the plugin will be available in the future since it is easier to pass maintainership if the original author decides to move on.

Can't agree more on this. Storing software on OSRF-maintained repo means a lot, maybe especially to experienced users.

Isaac

--
--
To unsubscribe from this group, send email to ros-sig-rqt+unsubscribe@googlegroups.com
Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
rqt: http://ros.org/wiki/rqt

[Aaron Blasdel]

I agree that this will level the plugin playing field, make dividing the labor easier and make maintaining the issues a lot less clunky. All the issues won't have to be prepended with the plugin name for example.

I feel like this would improve things for sure.

Do you need any help?
Aaron

[Dirk Thomas]

I have split the rqt_common_plugins repo. For plugins which I won't be able to maintain any longer I have created tickets to hand over to a new maintainer:

* https://github.com/ros-visualization/rqt_action/pull/1

* https://github.com/ros-visualization/rqt_launch/pull/15

* https://github.com/ros-visualization/rqt_py_console/pull/1

* https://github.com/ros-visualization/rqt_reconfigure/pull/6

* https://github.com/ros-visualization/rqt_shell/pull/3

* https://github.com/ros-visualization/rqt_top/pull/1

@Aaron You are currently listed as the maintainer for several packages. Are you planning to take an active role in reviewing incoming tickets and pull requests in the future or would you like to be removed from (some) packages?

Thanks,

- Dirk

[Isaac I.Y. Saito]

Just a comment.

> split these plugins into separate repositories. While increasing the number of repos it allows each repo to be maintained by a distinct person (or multiple) which can release that package at their own discretion.
>
> The effort to release the packages into a new distro is slightly higher (running bloom N times instead of once, but each invocation is also significantly faster). On the other hand any follow up release is much less work, and publishes less uselessly updated Debian packages.

That's absolutely true IMO. Because rqt_* packages less likely to
depend on each other, each package can be released without waiting for
another to become ready. In this case splitting repos per package
works great as already mentioned.

I recently started a conversation on ros-drivers[1] to consolidate
multiple, less active repos into a single repo to reduce the release
effort. Because there's a dependency tree between packages there,
making a release at once for all of those packages makes maintenance
effort far less, as opposed to rqt_* situation.

[1] https://github.com/ros-drivers/openni_launch/issues/30

- --- - --- - --- - --- Isaac

>> ros-sig-rqt...@googlegroups.com

>> Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
>> rqt: http://ros.org/wiki/rqt
>
>

> --
> --
> To unsubscribe from this group, send email to

> ros-sig-rqt...@googlegroups.com