package.xml Maintainers

[davetcoleman]

We would like to update the many package.xml files within ros-planning with up-to-date maintainers. I've started by scraping the current files and creating a editable table in Google Docs. I've removed @isucan @sachinchitta and Acorn because they have moved on to other projects/companies. Please add/move/remove your name from the spreadsheet as you see fit. Let's aim to have at least two per package. Your help in maintaining packages is greatly appreciated!

GDoc (no sign-in required)

Loose responsibilities of being a maintainer:

• You do not have to release the package, that is done at once for all MoveIt! packages, generally by @130s
• Help review PRs pertaining specifically to your package
• Fix regressions and code rot
• Help answer questions specifically about the package
• Maintain and improve package-specific documentation

@mikeferguson @rhaschke @v4hn @130s @sachinchitta @isucan @IanTheEngineer @gavanderhoorn @jrgnicho @dornhege @de-vri-es @ksatyaki @ipa-mdl @jonbinney

I can then convert this spreadsheet into a PR for all package.xml files, though I would greatly appreciate it if someone else could volunteer to do that.

[davetcoleman]

@kirstyellis since you spearheaded the benchmarking pull request effort, do you mind being a maintainer of that package? I would need your name and email.

[130s]

Because in moveit repo there are more than a dozen of packages. Since currently I'm taking care of release issues, I need to receive emails from ROS buildfarm whenever there's an issue.

Instead of adding my email to all the packages, I'm curious to create an email address or a mailinglist through which all related maintainers can receive notifications (I think there used to be such an address for moveit but not sure if it's still in use). I'm thinking of moveit-maintainers-release@googlegroups.com or something like that.

Thoughts, better suggestion, appreciated.

[v4hn]

Hm, is the current situation such a big problem for you?
I mean, there are status pages online for the current build-state of each package, right?
I would like to avoid adding a generic "moveit-maintainers-release" address to each package.xml,
but I agree that adding you to each and every package is not that great either.

[130s]

For example for Lunar, for which MoveIt! isn't properly released yet,

• I received on May 20th Jenkins build is back to normal : Kdev__moveit__ubuntu_xenial_amd64 #106
• But there's still a build failure in one of the contained packages, MSA (e.g. Yakkety), for which I haven't received any notice because none of my email is listed as a maintainer.

I initially thought getting notice for the metapkg, moveit, should've been sufficient hoping the notice from sub packages would escalate to the metapkg, but that doesn't seem to be the way it is.

[davetcoleman]

I'm not a fan of the overhead of maintaining an anonymous moveit email address either, I'd rather you add yourself to every package. But if its really important to your ability to do the valuable release work for MoveIt you do, I understand

[130s]

I created a mailinglist just for receiving notification purpose.
I've directly added some of you as an admin so that in case of necessity y'all can make change too (I don't expect that to happen though). I also set that you all don't receive any email post to this list.

I'm a fan of pull/merge request system even for the small change like updating maintainers, but when it comes to a large package set like MoveIt!, changing all packages every time there's a change in email address or the maintainers could become unbearably cumbersome, so allow me go ahead this way.

I'll open a PR to add this new address as a maintainer.

[BryceStevenWilley]

Both @130s and @davetcoleman's PRs have been merged (in addition to further maintainer maintaince like CODEOWNERS), so I'm closing this again.