Beware, this is an old proposal

This proposal is superseded with this one: CollaborativeMaintenance

Proposal to handle orphaned packages

Following the mail that Raphaƫl Hertzog published on the debian-qa mailing list, a proposal for a better handling of orphaned packages arised. This document will sumup the ideas behind all the thread, in order to clarify what we can do to better handle orphaned packages.

What is wrong with Debian orphaned packages?

Nothing but since we're about QA, we want to do always better.

The main problem with orphaned packages is that we don't find a new Debian maintainer. But in some cases, we have volunteers outside of Debian willing to maintain the package... but those volunteers can't afford to spend the time needed to become an official Debian maintainer. The package already exists and thus the packaging effort is minimal. The new maintainer process is a barrier for those contributors.

This proposal aims to create an infrastructure so that external contributors can maintain some packages with the help of some members of the QA team. At the same time, we can use this new infrastructure to maintain all orphaned packages in a more centralized manner.

We want to setup a system that would allow external developers to patch our orphaned's source packages and let the Debian QA Team overlook the resulting package, and upload it if needed.

This not an adoption, but rather a collaborative work between external developers (who focus on the code of the software) and the QA Team who, as usal, focuses on enhancing the quality of orphaned packages.

We want to make all this process as smooth as possible.

How would it look like?

The Debian QA SVN repository

All the orphaned packages would be (automatically) integrated in a subversion respository so that all packages can be handled with svn-buildpackage. The SVN repository is hosted on and access is controlled via the {alioth:collab-maint}.

The repository would contain 3 directories:

The orphaned directory will basically host every orphaned packages (the import should be done automatically whenever the package is orphaned by an upload to the archive).

The ext-maint (externally maintained) branch will host every packages for which an external developer waved and proposed his help. Those contributors would be listed somewhere so that we can "ping" them when needed.

Of course, when the status of a package changes, we can easily move the sources from one directory to another one. The move from the orphaned branch to the ext-maint one should be manually performed, by a Debian member of the QA Team.

This will allow us to easily see which packages are totally orphaned (no one cares, even outside Debian) and which ones are not.

Remarks concerning the SVN repository

We could use ACL possibilities to give automatic read/write access to all Debian developers.

We can also write some subversion hook scripts:

For a smooth transition to subversion, the system could automatically detect upload of orphaned packages generated from another source (and mail the uploader and import his changes). This is possible because svn-buildpackage should create a tag for each version built and uploaded.


Along with this repository we need a webpage listing the orphaned packages and their status :

A first draft of such a page has been written.

Expected benefits

As a side note, this system (or a copy of it) can also be used by people in the New Maintainer process to handle their packages... this would help the sponsor to review the changes.

External Contributors

External contributors/developers are people who use an orphaned package, know how to patch it, and are ready to help Debian to ensure that the package stays in a good shape.

On the other hand, those people just don't want to enter the long NM process or go through the harrasment of finding a sponsor to adopt the package, they just want to give support for the sources, to help the QA Team.

We find sad that orphaned packages might have several patches in the BTS lying for years. This proposal aims at minimizing the work of the QA Team, and thus, maximizing the upload of orphaned packages.

Those external developers should be added in the alioth qa project when they want to provide patches for an orphaned package.

They can then commit all the patches they want and ask a Debian member of the QA team to review and upload the package when needed.

What should be done

Everything. We have an empty SVN repository, that's all.

When everything is ready, we should communicate a lot about that, so that people know that external developers are needed for these packages. A first interesting work might be to contact upstream for each orphaned package (if it exists), and ask if someone wants to become an external developer for Debian.