Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 28 commits into
base: master
from
Open
Changes from all commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
0d5b63c
add rep-0152.rst
k-okada Dec 27, 2017
9f7e41b
Orphaned package is not the first time release, that's correct.
k-okada Feb 15, 2018
0728320
wrap before new sentence
k-okada Feb 15, 2018
0a4f031
put 3. Adopting packages, before 2. Releasing orphaned packages
k-okada Feb 15, 2018
f7062b7
note that releasing include run bloom-release and also act on notific…
k-okada Feb 15, 2018
5e5bc9d
fix layout
k-okada Feb 15, 2018
caaa105
This is a reference, not rationale.> , see https://github.com/ros-inf…
k-okada Feb 28, 2018
42b3dc4
Discourse categories is better than e-mail, because that is more easy…
k-okada Feb 28, 2018
e88cc35
remove extra empty lines
dirk-thomas Feb 11, 2019
3eb7471
fix typos?
k-okada Feb 19, 2019
81d1587
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
0b8134e
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
e8a2e5d
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
9b4c711
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
a6e833d
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
d2c5dc2
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
da43c68
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
516c190
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
737e311
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
8af4f24
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
00b0598
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
7506482
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
38fe053
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
0a29795
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
832e5c1
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
0eb78c9
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
05f0fd0
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
4f2101f
grammatical changes/fixes by @JWhitleyAStuff
JWhitleyAStuff Feb 25, 2019
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.
+142 −0
Diff settings

Always

Just for now

Copy path View file
@@ -0,0 +1,142 @@
REP: 152
Title: Orphaned Package Maintaining
Author: Kei Okada
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Dec-2017

Outline
=======

#. Abstract_
#. Motivation_
#. Reference_
#. Operations_
#. References_
#. Copyright_

Abstract
========

This REP specifies how we can organize and release packages without active maintainers.

Motivation
==========

As the size of the ROS ecosystem grows, some packages will lose active maintainers.
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]_).
Ideally, everyone wants to use a newer ROS distro which contains a set of packages almost equivalent to the set of packages in the previous ROS distro.

It is understandable that the original maintainer of a package might not continue serving as an active maintainer due to starting a new project, moving institutions/companies, losing interest, and so on.
Being a maintainer is not an easy job.
It includes responding to incoming questions and issues, checking for proposed changes and deciding to add them to the main source tree, and other responsibilities.

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 volunteers of the release maintainers group will enable the community to continue using the same set of packages from previous ROS distros with minimal community effort.
To this end, we followed the Debian QA Group system and the Debian Developer's Reference ('Dealing with inactive and/or unreachable maintainers'[3]_), which is considered non-normative, but best practice.

In ROS, we use 'Unmaintained' package status([4]_) and ROS Orphaned Packages Group([5]_), who do not have to take full responsibility for package maintenance jobs but are expected to take minimum responsibilities which mostly include releasing their packages into newer ROS distros.

Reference
=========

REP-0140 [6]_ and REP-0141 [7]_ provide maintainer information in package manifest file and maintainer status in ROS distribution file.
This conversation was marked as resolved by dirk-thomas

This comment has been minimized.

@gbiggs

gbiggs Feb 22, 2018

This is a reference, not rationale.


Maintenance Guide in ROSWiki [8]_ provides how to claim maintainership for orphaned packages.
This conversation was marked as resolved by dirk-thomas

This comment has been minimized.

@gbiggs

gbiggs Feb 22, 2018

This is a reference, not rationale.

This comment has been minimized.

@k-okada

k-okada Feb 28, 2018

Author

@gbiggs thank you for your comment use "reference" here and above.


Operations
==========

1-A. Orphaning a package by maintainers
This conversation was marked as resolved by dirk-thomas

This comment has been minimized.

@dirk-thomas

dirk-thomas Feb 12, 2018

Member

With the current proposal I don't see a way to distinguish the following two cases:

  • The group of orphaned package maintainers "chooses" that a specific package is orphaned, updates the manifest accordingly and starts doing releases of that package
  • A maintainer who can no longer maintain a package updates the manifest accordingly.

From a users point of view it would be nice to be able to distinguish these two cases. In the first case there is the expectation that there will be releases in the future. In the second case likely not (until the orphaned package maintainers actually "accept" the work and start doing releases for that package).

This comment has been minimized.

@k-okada

k-okada Feb 15, 2018

Author

@dirk-thomas thank you for comments, i have fixed most of comment. On this comment, A. Orphaned a package by maintainer corresponds to
A maintainer who can no longer maintain a package updates the manifest accordingly.
and if some of maintainer want to maintain the package by the orphaned team, I expect they choose Orphaning a package by users, not as a member of the team, but as an individuals.

To minimize the effort of orphaned maintainers, I intentionally remove the process of something like the group of orphaned package maintainers "chooses" So in both cases, user might be not sure if the packages will be releases in the future. To put such responsibility to the orphaned team feel to much for me. How do you think?

This comment has been minimized.

@dirk-thomas

dirk-thomas Feb 15, 2018

Member

So for all packages marked as "orphaned" in the manifest files there is no information which ones are going to be released by the group, right? I think it would be valuable for users to differentiate them but I understand your rational why the group doesn't want to "promise" that.

This comment has been minimized.

@k-okada

k-okada Feb 15, 2018

Author

Yeah, my first thought on this, is to create the organization like ros-unmaintained and once the package is marked as orphaned, then we transfer the package to that organization. If so everyone can see who is going to (or able to ) release these package, by looking at the "users" or "teams" of the organization.
But the draw back of this idea is that the location of the package will be moving around... If we can create github teams across different organization, then it would be great.
c.f. https://discourse.ros.org/t/releasing-repositories-form-other-people/1797/11?u=k-okada

This comment has been minimized.

@dirk-thomas

dirk-thomas Feb 15, 2018

Member

the draw back of this idea is that the location of the package will be moving around

👎 on moving repos around just to indicate their status. It generates quite some friction which is unnecessary.

---------------------------------------

If you can no longer maintain your package.

a. Set the package maintainer section in the ``package.xml`` file as follows.

``<maintainer email="ros-orphaned-packages@googlegroups.com">ROS Orphaned Package Maintainers</maintainer>``

b. Post a message to the `ROS Discourse Release Category <http://discourse.ros.org/c/release>`_ indicating that package is now orphaned.
Wait for response from someone in the ROS Orphaned Package Maintainer team.

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

1-B. Orphaning a package by users
---------------------------------

If you find a package is not actively maintained and are willing to release as a ROS Orphaned Package Maintainer.

a. Contact the current maintainer, ask for a transition to orphaned package and request access to the source and release repository to make releases.

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.

1. If the repositories are hosted on GitHub within a `ros-` org unit, the admins of the org group will usually grant the necessary access to these repositories.

2. If no one else aside from the original author (who doesn't respond) has access, you should fork the repository.

c. Add ROS Orphaned Package Maintainers to the maintainer section of package.xml as follows.

``<maintainer email="ros-orphaned-packages@googlegroups.com">ROS Orphaned Package Maintainers</maintainer>``

2. Adopting packages
--------------------

Orphaned packages are seeking a new maintainer.
If you are willing to step forward as an official package maintainer (not just releasing into new ROS distros but also respond to issues, pull requests and so on):
Contact to the ROS Orphaned Package Maintainers by posting a message to the `ROS Discourse Release Category <http://discourse.ros.org/c/release>`_.

3. Releasing orphaned packages
------------------------------

a. The package release process is the same as for standard packages, so please follow bloom tutorial titled ``Releasing into a new ROS Distribution`` in the ROS wiki documents [9]_ to release the orphaned package.


1. Update the maintainer section in the ``package.xml`` file indicating that the package is orphaned and commit to the source tree before you run the ``catkin_generate_changelog`` command.

2. During ``bloom-release`` process, you will be asked to set maintenance status.
Choose ``unmaintained`` . ::
::

Would you like to add a maintenance status for this repository?' [Y/n] Y
Please enter a maintenance status.
Valid maintenance statuses:
- developed: active development is in progress
- maintained: no new development, but bug fixes and pull requests are addressed
- unmaintained: looking for new maintainer, bug fixes and pull requests will not be addressed

This comment has been minimized.

@gbiggs

gbiggs Feb 22, 2018

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.

This comment has been minimized.

- end-of-life: should not be used, will disappear at some point

b. Add your package to the list of orphaned packages in `ROS OrphanedPackage page <http://wiki.ros.org/OrphanedPackage>`_ of ROSWiki.

4. Joining ROS Orphaned Package Maintainers
-------------------------------------------

To join ROS Orphaned Package Maintainers, please subscribe to the ros-orphaned-packages@googlegroups.com mailing list and also add your name and GitHub account to the `ROS OrphanedPackage page <http://wiki.ros.org/OrphanedPackage>`_ .

References
==========

.. [1] Releasing repositories form “other” people (https://discourse.ros.org/t/releasing-repositories-form-other-people/1797)
.. [2] Add usb_cam to ROS Kinetic main repository (https://discourse.ros.org/t/add-usb-cam-to-ros-kinetic-main-repository/607)
.. [3] Dealing with inactive and/or unreachable maintainers (https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#mia-qa)
.. [4] ROS distribution files, Release File (https://github.com/ros-infrastructure/rep/blob/master/rep-0137.rst#release-file)
.. [5] ROS Orphaned Packages Group (ros-orphaned-packages@googlegroups.com)
.. [6] Package Manifest Format Two Specification, Data Representation, maintainer (https://github.com/ros-infrastructure/rep/blob/master/rep-0140.rst#data-representation)
.. [7] ROS distribution file, Distribution file, status (https://github.com/ros-infrastructure/rep/blob/master/rep-0141.rst#distribution-file)
.. [8] Maintenance Guide, Claiming Maintainership (http://wiki.ros.org/MaintenanceGuide#Claiming_Maintainership)
.. [9] Releasing catkin packages (http://wiki.ros.org/bloom/Tutorials/ReleasingForANewROSDistro)
Copyright
=========

This document has been placed in the public domain.

..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.