Sign me up Login

About Sponsoring

The sponsorship process

A RFS is a request for sponsorship. If you have a package to be uploaded to Debian, you should file a bug against the sponsorship-requests pseudo-package containing information about your package.

Asking for Sponsorship

In general sponsor requests should be handled through the Debian Bug Tracking System. Please make sure both reports and comments are sent to the bug report ( only. A copy is going to be sent to the debian-mentors mailing list automatically by the bug tracker.

Once a source package has been prepared and made available (for example by uploading it to this site) file a new bug report against the sponsorship-requests pseudo-package by using the template below.

You might not receive a reply to your request if you do not subscribe to the debian-mentors mailing list or to your sponsorship-requests bug. You can subscribe to the mailing list and follow simple steps to confirm your subscription request. It can also take time for sponsors to look over the requests, so please do not give up quickly and keep a watch over the mailing list. You can browser other packages and give other people feedback while you are waiting.

Template for an RFS bug

Send the filled out template below by mail to our pseudo-package. If you prefer, you can also use the reportbug tool.

From: J. Maintainer <>
Subject: RFS: hello/3.1-4 [put in ITP, ITA, RC, NMU if applicable] -- 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":

 * Package name    : hello
   Version         : 3.1-4
   Upstream Author : [fill in name and email of upstream]
 * URL             : [fill in URL of upstream's web site]
 * License         : [fill in]
 * Vcs             : [fill in URL of packaging vcs]
   Section         : [fill in]

It builds those binary packages:

  hello - friendly greeter

To access further information about this package, please visit the following URL:

Alternatively, one can download the package with dget using this command:

  dget -x

Changes since the last upload:

[your most recent changelog entry]

  J. Maintainer

Please indicate in the subject if the package fixes RC bugs, is a QA or NMU upload or a new package or a package you adopted:

  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

The meaning of this shortcuts is denoted below, in case you are unsure:

ITA stands for Intend to adopt. These are packages which were orphaned in the past and you intend to adopt.
ITP stands for Intend to package. These are packages which not exist in Debian yet. Such packages need to go through NEW. That is the queue on ftp-master for packages uploaded for the first time, which need to be reviewed first. This includes renames, packages moving between areas, and source-packages that build new binary packages.
You upload is a QA upload. Please refer to the respective section in the developer's reference to learn about QA uploads.
This is short for "Non-Maintainer Upload"; a version of a package that is not uploaded by the official Maintainer of a package, but rather by you. For NMUs special rules apply. Please see the developer's reference again.
This is short for "Release-Critical". That is a class of bugs which are particularly important. Use this indication if your request fixes such RC-bugs.

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. We collected hints to review package on a a dedicated page.

Please send any comments to (please do not send carbon copies to reviewers or bug submitter - assume they are subscribed to the mailing list unless they explicitly ask you to send them carbon copies). You can use the following tags to indicate progress:

open questions or changes are required before an upload. The package needs work before it can be uploaded.
somebody did a brief review the package and it looks sane. It can still have (smaller) issues that need to be fixed before an upload.
somebody is willing to look after the package until it is uploaded.
large problems or cannot not be uploaded at all.

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
$ bts tag nnn +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.


People are advised to close inactive requests after a longer term of no activity (we consider two weeks for requests tagged wontfix, six weeks for requests tagged moreinfo and six months for others appropriate). The same applies to uploaded packages for which the sponsor forgot to close the RFS bug.