[Documentation] [TitleIndex] [WordIndex

This page is designed to provide a guide for package maintainers. It will include an overview of the roles and responsibilities of a package maintainer as well as provide some checklists which maintainers can follow.

Purpose of a Maintainer

The purpose of maintaining a package is to ensure that the package is available to the community by releasing it with bloom and to support the package by servicing pull requests and acknowledging issues, but not necessarily addressing issues. The maintainer provides a point of contact for the community to keep track of the state of the package. This is a very important role as it provides access to the current development for the whole community.

Role of a Maintainer

Responsibilities of a Maintainer

Maintainership is declared on a per Distribution basis. This gives a clear time scope on the commitment for being a maintainer. When allocating maintainership positions, priority will be given to past maintainers for continuity. The duties of a maintainer should be a couple hours per Distribution. These are some of the responsibilities of a maintainer:

Perks of Being a Maintainer

By being a maintainer for one or more packages you are helping the community stay up-to-date and more useful for others. Additionally, you gain recognition as a contributor to a package which many others likely use. Finally, you get some influence on the direction of a package. Since you will be helping service pull requests and issues, and will likely have an opportunity to help with development, you get the chance to steer the direction of the development such that it better suits your needs. With that being said, you should avoid ignoring other use cases and users, this process works best when we can collaborate on packages rather than encouraging people to fork off new packages because they could not use the common one.

Terminology

There are some terms in common usage when maintaining a package.

Repositories

The upstream repository is the main repository where the code for the package is stored and worked on. This is the repository on which issues and pull requests will be opened. The release repository is a separate repository that contains metadata useful for doing releases of the upstream repository into ROS. Almost all existing packages already have a release repository. The rosdistro repository contains a master list of which packages are available in which ROS distribution.

Distributions

There are two concepts of distribution in ROS. The first is the ROS distribution that contains the ROS packages. The second is the Linux distribution that a ROS distribution is released for. Each ROS release is built for one or more Linux distributions that is decided upon at the release time of the ROS distribution.

Current Maintenance Status

A summary for each Distribution can be found at http://repositories.ros.org/status_page/

Understanding the repositories.ros.org status_page

There is a lot of information on the repositories.ros.rog status page, so this is a short walkthrough of what some of that information means. For this example, click here.

The main status page for a ROS distribution shows every released package. To see just the packages you are interested in, you can use the text box in the top left (the text box is a simple search, no globbing or regex). For each line below the search text, there are a number of fields:

Understanding the CI (Continuous Integration) build farm

All packages listed on repositories.ros.org are backed by a number of jobs on the backend build.ros.org. There are thousands of these jobs, each one automatically generated when a new package is added to the ROS distribution. Each job follows the same basic short name as described in the #repos section. This is where you can find information on why a job is failing, what the current status of the jobs are, etc. This is also a place to find out what downstream packages are dependent on your package, though the main package page on wiki.ros.org is more convenient.

Claiming Maintainership

If you find a package which you maintain but does not have the maintenance status set, set it in the release file (here , for hydro). See: http://reps/rep-0141.html#distribution-file

If you find a package which you do not maintain and the maintenance status is not set, and you are interesting in helping to support it, then you should try these things in order:

If you are listed as a maintainer for a package, but you cannot maintain it for this distribution, you should try these things:

Checklist For Package Maintainers

For each package that you maintain please make sure the following has been completed:

For catkin packages/repositories

Tutorials

How to make a release

See the bloom/Tutorials

How to submit a repository for documentation

How to submit a repository for continuous integration

How to host software


2017-09-23 12:19