5.13. Collaborative maintenance

Collaborative maintenance is a term describing the sharing of Debian package maintenance duties by several people. This collaboration is almost always a good idea, since it generally results in higher quality and faster bug fix turnaround times. It is strongly recommended that packages with a priority of standard or which are part of the base set have co-maintainers.

Generally there is a primary maintainer and one or more co-maintainers. The primary maintainer is the person whose name is listed in the Maintainer field of the debian/control file. Co-maintainers are all the other maintainers, usually listed in the Uploaders field of the debian/control file.

In its most basic form, the process of adding a new co-maintainer is quite easy:

• Set up the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as Git. Salsa (see salsa.debian.org: Git repositories and collaborative development platform) provides Git repositories, amongst other collaborative tools.

• Add the co-maintainer’s correct maintainer name and address to the Uploaders field in the first paragraph of the debian/control file.

  Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>

• Using the PTS (The Debian Package Tracker), the co-maintainers should subscribe themselves to the appropriate source package.

Another form of collaborative maintenance is team maintenance, which is recommended if you maintain several packages with the same group of developers. In that case, the Maintainer and Uploaders field of each package must be managed with care. It is recommended to choose between one of the two following schemes:

1. Put the team member mainly responsible for the package in the Maintainer field. In the Uploaders, put the mailing list address, and the team members who care for the package.

2. Put the mailing list address in the Maintainer field. In the Uploaders field, put the team members who care for the package. In this case, you must make sure the mailing list accepts bug reports without any human interaction (like moderation for non-subscribers).

In any case, it is a bad idea to automatically put all team members in the Uploaders field. It clutters the Developer’s Package Overview listing (see Developer’s packages overview) with packages one doesn’t really care for, and creates a false sense of good maintenance. For the same reason, team members do not need to add themselves to the Uploaders field just because they are uploading the package once, they can do a “Team upload” (see NMUs vs team uploads). Conversely, it is a bad idea to keep a package with only the mailing list address as a Maintainer and no Uploaders.