add rep-0152.rst for orphaned package maintainer info.

[k-okada]

based on discussion at https://discourse.ros.org/t/releasing-repositories-form-other-people/1797
Please also check http://wiki.ros.org/OrphanedPackage

@gbiggs, @v4hn, @7675t, @garyservin Please start review.

[dirk-thomas]

Nitpick: please start each sentence on a new line to avoid huge diffs for small changes.

[NikolausDemmel]

👍, REP looks good to me.

I have a few minor comments on language. Would you prefer comments or a PR on your branch?

[dirk-thomas]

Nitpick: wrap before new sentence.

[k-okada]

thank you . PR would be better. thanks

…

-- ◉ Kei Okada 2018-02-10 21:52 GMT+09:00 Nikolaus Demmel <notifications@github.com>:

👍, REP looks good to me. I have a few minor comments on language. Would you prefer comments or a PR on your branch? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#150 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeG3AHTY0GLzV0KOpsbtBMas9LTB5owks5tTZERgaJpZM4RNZbx> .

[NikolausDemmel]

thank you . PR would be better. thanks

Sorry I didn't get to it yet. I'll try to do it soon and send a PR.

[gbiggs]

Should probably also mention that when it becomes incompatible with a dependency, it will no longer be released unless someone contributes a patch to fix it.

[k-okada]

The message comes from https://github.com/ros-infrastructure/bloom/blob/ffd0f2acaf3329d5c25ab5d437c5c64d3c452a33/bloom/commands/release.py#L551, should we change bloom script ? @gbiggs

[v4hn]

I believe this initiative is as relevant as two years ago.
It will also become relevant for ROS2 in the not-too-distant future.

It would be nice to see this finally merged. @k-okada @gbiggs @dirk-thomas

[k-okada]

@v4hn Thanks i think this OK to merge @dirk-thomas

[dirk-thomas]

Before a REP draft is merged it should be announced on Discourse for wider visibility. Since the last communication about this draft has been more than a year ago I think it should happen again.

It might also be good to review the text for spelling and grammar since there seem to be numerous issues like that - starting at the title of the document.

[k-okada]

@dirk-thomas thanks for comments, I have fixed some typos, and annnouced on Discourse
https://discourse.ros.org/t/ros-orphaned-package-maintainer-info-rep-152-for-review/7906

[JWhitleyWork]

Please see my suggestions. They are mostly grammatical changes/fixes.

[k-okada]

@JWhitleyAStuff thanks for fixes. I have updated the PR.

[JWhitleyWork]

@JWhitleyAStuff thanks for fixes. I have updated the PR.

It looks like there are still a few more that are unresolved, unless my interface is just not updating. Click the "Load More..." link above under "8 hidden conversations."

[k-okada]

@JWhitleyAStuff ok, done.

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/baxter-release-permissions/8705/8

[130s]

Just wondering what's blocking the review/merge.

Wiki page http://wiki.ros.org/OrphanedPackage links to the URL assuming this PR is merged (which is not) so link is broken.

[clalancette]

I've added some additional questions for clarification. Once we have settled those, I think we can look at merging this.

[clalancette]

Suggested change

	c. Add admin permission of both source and release repository to who respond from in the ROS Orphaned Package Maintainers team.
	c. Add admin permission of both source and release repository to whomever responded from the ROS Orphaned Package Maintainers team.

[clalancette]

Also, what happens if the maintainer never gets a response? That's not ideal, obviously, but in the case it does happen, what should the maintainer do?

Relatedly, how long should they wait for a response? A week? A month?

[k-okada]

If that happens, it means Orphaned team/framework is not working. I think that's is out of the scope of this document. how do you think?

[clalancette]

This says that a single day isn't enough, but some guidance on how long would be appropriate. I'll suggest 3 months is sufficient time, though it is pretty long if a user is waiting for a package.

[k-okada]

how about (a single day isn't enough to conclude that. we ask users to be patient and wait for 3 month for at least.)

[audrow]

Suggested change

	b. If the current maintainer is not responsive (a single day isn't enough to conclude that) and you still want to release the packages, there are two different paths forward depending on the "location" of the source and release repositories.
	b. If the current maintainer is not responsive for three months and you still want to release the packages, there are two different paths forward depending on the "location" of the source and release repositories.

I think there could be some discussion on exactly how long this should be.

[clalancette]

This is what gets done in the end, but it doesn't tell the interested party what to do. In other words, I think we need a decision tree here which is something like:

• Contact the maintainer.
• Maintainer responded? ----> done
• Maintainer didn't respond after 3 months?
  • Send information to ros-orphaned-packages@googlegroups.com about the source repository, release repository, and where and how maintainer failed to respond.
  • If the ROS Orphaned Package Maintainers agree with your assessment, and the repository is hosted on GitHub within a ros- organization, the admins of the group can grant the necessary access.
  • If no one aside from the original author has access, you should fork the repository

[k-okada]

thanks for the comment, I have uploaded a fixed version. As for the last comment, do you mean we'd add something like
???

[clalancette]

Yeah, that is kind of the thing I was thinking of. Basically a clear set of steps that a person needs to go through in order to take over a package.

[k-okada]

@clalancette please check the diagram at #150 (comment), which includes all processes.

[audrow]

Shouldn't this figure be included as an image in this PR?

A note on the figure above: I think that if something happens or not should result in different branches. Something like this:

Contact maintainer ------------
|                             |
| responds within 3 month     | no response
|                             |
|                             v
|                            ...
v
Did they agree to transfer?-------
|                                |
| yes                            | no
|                                |
v                                v
Do transfer - done!             ...

[tfoote]

Are the orphan maintainers the right body to determine succession eligibility? That's a very different role than volunteer releasing. Currently this is not clearly defined and is the responsibility of the rosdistro release manager.

What is the process for adoption beyond contact? We should have a full cycle defined to not end up with the orphaned packages list growing unbounded.

[k-okada]

@tfoote The role of 'maintainer' is described at https://github.com/ros-infrastructure/rep/pull/150/files#diff-ad591b0fb51969339c5dbf52c2336309210bb7b1c89563afff9daca93bd2b911R31-R33 . I understand your concern, one idea is to hold an orphaned maintainer meeting and make a vote to judge that.
however in reality, due to the limited resource of an orphaned maintainer team, I think we will pass maintainership to everyone who requested. Even though we do not sure if they have enough resources/potential to maintain that. If that happens, the package simply goes back to the orphaned team.

[tfoote]

Yes, that's exactly my concern. You're patterning this on the debian model. However they have a very strong vetting process before someone is allowed to become a debian maintainer, with a process including sponsors and mentorship. We have been relying on direct succession planning and maintainer handoffs and adhoc reviews by the release managers. We cannot simply handoff maintainership to the first person who requests to do so even if they are not qualified.

This is exactly why I'm asking about the full cycle. We need to make sure that the whole process is sustainable and not just kicking the can down the road and putting an unsustainable burden on one or a group of people which will box us further into a tighter corner.

[k-okada]

@tfoote I totally agree on this. This document says "If you want to maintain a package, please post to ROS Discourse". But did not say how to deal with that request.

I am expecting some discussion will occur on Discourse and decide whether if we could pass the maintainership.
So how about adding

To pass maintainership to volunteers, you need at least two approvals from the ROS Orphaned Package Maintainers team. And a single day isn't enough to decide new maintainers, the team will wait for other candidates and make the decision for 3 months for at least".

??

I understand this proposal is a simplified debian model, and if we could have the strict process as debian, that would be great. I also share your concern about passing maintainership to someone who is not responsible for that. But to build a sustainable model that fits the current ROS userbase, I think passing maintainership as much as possible and increase the number of potential maintainers, I wouldn't say that we can pass maintainership to the first responders. Even if they failed to keep maintaining, we, the orphaned maintainer team, will backup the process.

So my suggestion here is to not go through the cycle step by step very carefully like debian, we choose to turn the cycle a little faster, (not as much as fast), to build up this orphaned package maintainer community.

[audrow]

My thoughts on first reading this are that maybe this should be two REPs:

• One for orphaned packages that will released by community members
• One for the process of having unmaintained packages adopted.

I think the later will require more discussion on if and how exactly we plan to do it.

For both parts, I think that the vetting process would have to be well thought out to avoid the security risk of having new and possibly unknown people jumping in to maintain packages that have community users.

I'm leaning towards a policy of let the maintainers figure it out (as we get out of their way and don't advocate for a system with possible security risks) and if some community member wants to release a package for a new version, they can fork the repository and then release it. I favor this because it is at least explicit that this may not be the same package that you were using on another distro.

FYI, we plan to have a larger discussion at Open Robotics in the next week on this, so there should be more opinions soon.

[audrow]

Suggested change

	The idea behind this document is to organize a team of volunteers who can do ONLY the release job, which includes sending the source tree to the ROS Build Farm and acting on notification emails form the builds.
	The idea behind this document is to organize a team of volunteers who can do ONLY the release job, which includes sending the source tree to the ROS Build Farm and acting on notification emails from the builds.

[audrow]

Suggested change

	b. If the current maintainer is not responsive (a single day isn't enough to conclude that) and you still want to release the packages, there are two different paths forward depending on the "location" of the source and release repositories.
	b. If the current maintainer is not responsive for three months and you still want to release the packages, there are two different paths forward depending on the "location" of the source and release repositories.

I think there could be some discussion on exactly how long this should be.

[audrow]

Shouldn't this figure be included as an image in this PR?

A note on the figure above: I think that if something happens or not should result in different branches. Something like this:

Contact maintainer ------------
|                             |
| responds within 3 month     | no response
|                             |
|                             v
|                            ...
v
Did they agree to transfer?-------
|                                |
| yes                            | no
|                                |
v                                v
Do transfer - done!             ...

[tfoote]

Overall I think that a more formalized way for passing the baton between maintainers is valuable. There's some good discussions of how to do that with guidance to announce it on ROS Discourse with a call for new maintainers. And a channel for new maintainers to reach out and volutnteer is also important and valuable.

However I'm generally against us creating what I see as a pending tragedy of the commons of a new "group of volunteers" who are expected to pick up and maintain, triage, prioritize and manage all the orphaned packages. There's inevitably going to be turnover in our community and handoffs will be required. If the process of handing off to the orphan maintainers is mostly procedural, but we are vetting adoptions. Unless we are very lucky, or more likely someone puts in a lot of effort to coordinate adoption the pool of orphaned packages will grow continuously.

As this pool grows the volunteers managing that pool will have less and less time to manage said packages. And if there's critical patches necessary for some package and they're already stretched out thin, how will they know that something critical has not been patched. Or who's job does it become to triage this? As someone who's often been at the core keeping track of these things that impact the community I've seen others and had to pick these things up myself.

From the end user's perspective having packages in this state of partial mainteance is also unfortunate as well. It means that things may be available, but can't necessarily be trusted without looking into the metadata as to whether there's an active maintainer or a collective without any real accountability.

Certainly non-expert maintainers can do releases, but if they're not actually experts in the field it may be a problem that the volunteers cannot effectively triage issues that come up if they're not familiar with the code base. Which is not something that you can expect from a pool of volunteers.

Another role that there may be no volunteers who are appropriately qualified to determine when something in the orphaned pool should be removed from the pool. And there's no proces for this called out. This is an important part of the process of development. When there are new tools that come out and supersede old ones the previous ones we should make deprecation cycles and manage transitions. However if there's not an expert on the package managing this anything that ends up in the orphaned packages pool can just languish there indefinitely.

And again looping back to the end users's point of view. We want the ROS ecosystem to be a collection of many useful packages for people. One metric of this is the number of packages. But if we have 100 maintained packages and 100 partially maintained packages versus having 110 fully maintained packages, and 90 unmaintained packages they could mine for examples but that they know won't work out of the box, I would posit that it would be better for new users to have the consistent experience of all packages being well maintained. Inconsistency of quality is one of the top complaints about ROS and if we do a half effort to maintain things we will perpetuate that.

With all that said I would like to circle back and suggest that this be refactored to focus on improving communications within the community and that the effort that we may seek from volunteers for making releases and doing a minimum of maintenance instead be pointed towards doing the outreach and matchmaking to find new maintainers and contributors. And not have a group that that is tasked with picking up all the pieces from the entire community. This is directly focused on our long term sustainability instead of focusing on a short term stop gap that will likely weigh us down in the long run.

[tfoote]

This is not a "standard" which something will be certified against but more of a potential process that people could follow if they'd like to participate in this process. This should be informational to be more easily revised.

[audrow]

Suggested change

	The main drawback of this situation is these packages do not get released into newer ROS distros which are released every year, even if they are commonly used (For example, USB camera drivers have not been released into Kinetic for more than half year [1]_ [2]_).
	The main drawback of this situation is these packages do not get released into newer ROS distros, which are released every year, even if they are commonly used (For example, USB camera drivers have not been released into Kinetic for more than half year [1]_ [2]_).

[clalancette]

Given the latest comments, I'm going to go ahead and close this one. If you think that we should still pursue this as an REP, please feel free to reopen.

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-1-and-python-3-10s-deprecation-of-distutils-core/29834/13