change maintainer to ROS orphaned package maintaner

[v4hn]

I do not believe it's a good idea to declare all packages in PR2 unmaintained.

Instead I would propose to add (on request) known developers with access to an actual PR2 (this includes @k-okada , myself and obviously multiple others) as organization owners of the PR2 organization and set all repositories to approval-required-for-merge. All of us are experienced developers, so if we invoke the 4-eyes principle, this should be fine. @k-okada @TheDash If you both are ok with that approach, I would propose that @k-okada and myself get full access here and can include other maintainers whenever they want to join in.

We finally have to get these code bases moving again and I discussed similar ideas with @k-okada and maintainers from IAS Bremen (I don't know any github ids, could you please link Alexis et al @k-okada?) recently.

Imho the bigger problem is actually https://github.com/pr2-debs which automatically builds debs on commit. (@TheDash is this still the case?) Given that many groups have custom installations&configurations I would actually opt for deprecation of the whole organization. But this is a matter to discuss in that organization instead.

[k-okada]

hi @v4hn Sorry for late, I have two different standpoint for this topic.

One is an activity to save packages from orphaned situatiation, as described in https://github.com/PR2/rqt_pr2_dashboard/pull/19#issuecomment-357851365 . My thought on this approach is to set these packages an 'unmaintained' status and group of volunteer package maintainer take care of it, with minimum efforts. So this activity is not limited to pr2 related package, but all packages currently released. From this point of view, if we do not have active maintainer for this PR2 package, then we will put 'unmaintained' tag, and ask maintainer group to continue releasing this into up coming ROS distros. The PR here is based on this standpoint.

The other one is as a PR2 user. I agree that if we could find a team of PR2 developers, then we can set us as the maintainer of PR2 package. Maybe @amaldo from Bremen, @jjclark1982, @awesomebytes from Sydney?

So if we can have an enough team of PR maintainer at this moment, then we could ask them to become a maintainer of this package, if not, we first set this as a 'unmaintained' and wait for new maintainer.

[awesomebytes]

Hello everyone, I offer myself as a maintainer, just accept the https://github.com/PR2/rqt_pr2_dashboard/pull/21 I made and give me permissions. I at least have access to the PR2 in our lab (I maintain it), so I can do some minimal maintaining work.

[UltronDestroyer]

Imho the bigger problem is actually https://github.com/pr2-debs which automatically builds debs on commit. (@TheDash is this still the case?)

I'm not sure. That was the case in August 2017 when I left Clearpath. You'd have to ask them what the current status is.

If there is no organization or someone paid to do it, it's really hard IMHO to say it's maintained by a specific person unless they have specific private interests in the matter. So, I agree with @k-okada that it should be left "unmaintained" and that any work that does happen is volunteered, not expected, and not required.

Self advertisement: If there is any work regarding this required by any of your organization in the robotics software realm, I'd be interested in helping out as I'm currently supporting myself w/ contract work.

[v4hn]

and that any work that does happen is volunteered, not expected, and not required.

This is normal in community-based open source software maintenance. I assume the statement is true for 60-90% of all packages released in rosdistro. And they are considered maintained (this includes, among other things MoveIt). This approach is different from paid support, but it can work equally well and better if the packages are of interest.

@k-okada @awesomebytes and myself (@amaldo probably can be included here to?) all administrate/supervise PR2 robots in our respective labs, so we all have an interest in the packages in the PR2 organization.

Pragmatically speaking, @k-okada and myself are part of the orphaned-packages movement and PR2 users, so either way this thread hopefully ends in (at least) both of us having administrative access to the organization. Who will be added to which package's maintainer field and which packages we set to unmaintained can be discussed in an independent video conference/discourse thread once someone in addition to you, @TheDash, has access to the organization.

As @awesomebytes just demonstrated in a PR, there is clearly interest to maintain packages actively. I feel pretty much the same way.

[UltronDestroyer]

This is normal in community-based open source software maintenance.

This is not true in ROS' case. I would bet to believe many people are funded by universities/start-ups/private funding to do the work that they do. At one point I was maintaining 6.83% of all ROS packages and I was paid, with 5 people from the OSRF employees maintaining another 40%+ of packages, so I know you're wrong there. It's not hard to get the data for this fact just have to visit http://repositories.ros.org/status_page/ros_kinetic_default.html and group the maintainers by organizations. So in ROS case, this is not "normal".

As @awesomebytes just demonstrated in a PR, there is clearly interest to maintain packages actively. I feel pretty much the same way.

There may be individual developer interest. But organizational interest is lacking. It was a full time effort to maintain the PR2 to what extent that I did it and I believed I severely could have used more help maintaining it with the amount of people that used these packages. Not only that but we asked many organizations years ago to help maintain it/pay for support and there was an overwhelming "no" response from the community.

We could gather a list of active supporters and divy up the entirety of the organization's packages (e.g everything I maintained, about ~100 ish ROS packages) among them to delegate responsibility going forward.

What's a good number of packages everyone here is individually able to take on? I know you all already maintain a lot of packages so taking on a huge chunk would just end up distracting you from your focus.

[v4hn]

I would bet to believe many people are funded by universities/start-ups/private funding to do the work that they do.

Yes, many of them are not paid to maintain FOSS packages though. They are paid to get their job done. In academia doing software maintenance is often frowned upon, because you "could do research" instead. At the same time everyone is happy somebody still does it... Anyway, that debate doesn't really belong in this issue.

What do you want interested parties to do/provide/establish in order to add them as organization owners of the PR2 organization? Do you intend to stay the only owner and only assign write permissions per package if somebody steps up for a specific package? As far as I can see you did not touch any of these packages in almost half a year. I proposed to add proven PR2 maintainers as owners on request.

Of course you are right about the amount of work. It is almost impossible for a single individual to ensure functionality of the whole PR2 stack and I believe this is not the current goal either. As you probably know best, quite a lot of PR2-related packages did not fully work since fuerte or hydro.

[k-okada]

I have released pr2 related packages into kinetic as a Orphaned Maintainer [ https://discourse.ros.org/t/maintaining-and-releasing-orphaned-packages/3929 ], which basically take care of releasing into new distros,

I have created kinetic-devel branch for most of repositories, and merged some of PR's and released in to kinetic. But seems most of PR is very reasonable and should work to indigo. If some of you have tested these kinetic-branch source tree, I'll release kinetic branch source into indigo distro.

If someone here would like to take over the maintenance role, feel free to ask me.

• http://github.com/pr2/pr2_simulator
• http://github.com/pr2/pr2_apps
• http://github.com/pr2/pr2_kinematics
• http://github.com/pr2/pr2_ethercat_drivers
• http://github.com/pr2/app_manager
• http://github.com/pr2/pr2_common_actions
• http://github.com/pr2/willow_maps
• http://github.com/pr2/pr2_controllers
• http://github.com/pr2/pr2_mechanism
• http://github.com/pr2/pr2_common
• http://github.com/pr2/pr2_mechanism_msgs
• http://github.com/pr2/rqt_pr2_dashboard
• http://github.com/pr2/pr2_power_drivers