A new pseudo-package called sponsorship-requests was created[3] in Debian's bug tracking system, to help handling sponsorship requests. A proposed workflow is explained below. It is based on an earlier discussion on the debian-mentors list[1].

The workflow will also be made available on [2].





Currently there are three ways to ask for sponsorship of an upload to the Debian archive: uploads can be requested via a packaging team, via private mail to a (known) developer or via public mail to the debian-mentors lists.

Sponsorship in teams can work very well, for example in the Debian Perl Group, but some other teams do have a lack of developers. For these people and maintainers of packages that do not fit in any existing team, the only way to ask for sponsorship is often the third route: the debian-mentors lists. However the current procedure is (too often?) disappointing for both sponsorees [1][2], but also for developers who lost any interest in sponsoring packages [3].

Problems with the current handling of debian-mentors requests include in our opinion:

We propose to use the BTS to handle sponsoring requests. Both sponsorees and sponsors should already be familiar with its usage and we hope it will improve the sponsoring process for both sides. It will also make it easier to analyse sponsoring (e.g. number of requests without a response).

We hope this will make it easier to sponsors to seek requests that still need attention and encourages more developers to sponsor uploads. We also hope to encourage peer-review of packages by other non-developers. Further suggestions on improvements or simply reasons why you do not sponsor uploads or what other problems you have with the current procedure or our proposed workflow are of course welcome.





Proposed workflow

In general all mails should be sent to the RFS request ( Please also Cc the submitter ( A copy will be sent to the mailing list automatically by the bug tracker.

Asking for sponsorship

Once a source package has been prepared and made available (for example via [1]), file a new bug report against the sponsorship-requests pseudo-package:

Subject: RFS: hello/3.1-4 -- friendly greeter

Package: sponsorship-requests
Severity: normal (important for RC bugs, wishlist for new packages)

Dear mentors,

I am looking for a sponsor for my package "hello":

dget -x

It builds these binary packages:

  hello - friendly greeter

More information about hello can be obtained from

Changes since the last upload:

hello (3.1-4) unstable; urgency=low

  * Adopt package. (Closes: #123457)
  * Fix typo in package description. (Closes: #123456)

 -- J. Maintainer <>  Sat, 10 Dec 2011 22:17:05 +0100

J. Maintainer

Please indicate in the subject if the package fixes RC bugs, is a QA or NMU upload or a new package (closes an ITP):

  Subject: RFS: hello/1.0-1 [ITP] -- friendly greeter
  Subject: RFS: hello/1.0-3 [QA] -- friendly greeter
  Subject: RFS: hello/1.0-1.1 [NMU] [RC] -- friendly greeter
  Subject: RFS: hello/1.0-2 [RC] -- friendly greeter
  Subject: RFS: hello/1.0-2 [ITA] -- friendly greeter
  Subject: RFS: hello/1.0-2~bpo60+1 [BP] -- friendly greeter

Please keep track of the bug and respond to comments. If the bug was tagged moreinfo or wontfix and you think you have addressed the issues, please remove the respective tag again.

If you changed the package to address concerns, please send a follow-up to the sponsoring request (To: that includes the URL to the source package and the last changelog entries similar to the initial request.

If there are issues with the upload after the bug was closed, for example when the package was rejected by the archive software, you can reopen the bug (again, please include references to the updated source package or ask for advice).


Reviewing packages

Anybody feeling competent enough is invited to review sponsoring requests. You do not need to be a Debian Developer to do so.

Please send any comments to (Cc: nnn-submitter@bugs.d.o). You can use the following tags to indicate progress:

If you intend to take care of the sponsoring request until the package is ready for upload, please consider setting yourself as the owner of the bug and tag the bug pending: $ bts owner nnn , tag it + pending

Uploading packages

After you uploaded a package, please close the bug report by sending a mail to Do not close RFS bugs in debian/changelog. It is the sponsor who solves the issue, not the supplier of the package or anyhow related to the package itself.


Inactive requests should be closed (semi-)automatically after a longer term of no activity (two weeks for requests tagged wontfix, six weeks for requests tagged moreinfo and six months for others). The same applies to uploaded packages for which the sponsor forgot to close the RFS bug.


A short summary intended usage of tags:


A few usertags have been proposed (and are being experimented with) for the Wheezy freeze period:

To set such a tag on an existing bug report, send a mail to control@b.d.o starting with something like:

package sponsorship-requests
usertags NNNNNN not-fit-for-wheezy

As of writing, those usertags are used by default to sort the bug list. See Mentors/UserCategories.

Ideas for future improvements

Integration with debexpo (mentors.d.n)

A tight integration of the code base is not possible due to lack of time of its maintainers (any help is appreciated!), but changing or introducing templates to reflect a new BTS workflow is possible immediately. Thus, the lack of code support on mentors.d.n side is certainly not a show stopper.



In previous discussions two main concerns were raised:

Why not use the wnpp pseudo-package?[1]

We believe a separate pseudo-package would be better as this would make it easy to direct sponsorship requests to the right people. The wnpp pseudo-package already has much traffic unrelated to this resulting in a lower signal-noise ratio.

Wouldn't a specialized application be better than using the BTS?[2]

People should already be familiar with the BTS. Using a special interface for sponsoring requests would create more inertia (and somebody would have to design such an application first). We hope however for a better integration in the debexpo software that runs in the future (of course this would also require someone working on it, see the previous section).