The sponsorship process
An 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, sponsorship requests should be handled through the Debian Bug Tracking System. Please make sure both reports and comments are sent to the bug report (nnn@bugs.debian.org) only. A copy will 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 browse other packages and give other people feedback while you are waiting.
Template for an RFS bug
Send the completed template below by email to our pseudo-package. If you prefer, you can also use the reportbug tool.
From: J. Maintainer <j@example.com> To: submit@bugs.debian.org 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 contact : [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] The source builds the following binary packages: hello - friendly greeter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hello/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hello/hello_3.1-4.dsc Changes since the last upload: [your most recent changelog entry] Regards, -- J. Maintainer
Please indicate in the subject line if you are adding a new package to Debian (ITP), if you are adopting an existing package (ITA), or if you are fixing bugs in an existing package (via NMU or QA). If your upload also fixes Release Critical bugs, please add the RC indicator as well.
Subject: RFS: hello/1.0-1 [ITP] -- friendly greeter Subject: RFS: hello/1.0-2 [ITA] -- friendly greeter Subject: RFS: hello/1.0-1.1 [NMU] [RC] -- friendly greeter Subject: RFS: hello/1.0-3 [QA] -- friendly greeter Subject: RFS: hello/1.0-2 [RC] -- friendly greeter
The meaning of the indicators above is described below:
- ITP
- ITP stands for Intend to package. These are packages that do not exist in Debian yet. Such packages need to go through the NEW queue, where they are reviewed by an FTP Master. Packages that must go through NEW include renamed packages, packages moving between areas, and source packages that build new binary packages.
- ITA
- ITA stands for Intend to adopt. These are packages which were orphaned in the past and which you intend to adopt.
- NMU
- Your upload is a Non-Maintainer Upload, a version of a package that is not uploaded by the official Maintainer of a package, but rather by you. Special rules apply to these uploads. Please refer to the Developer's Reference for more information.
- QA
- Your upload is a QA upload. Please refer to the respective section in the Developer's Reference to learn about QA uploads.
- RC
- This is short for Release-Critical, a class of bugs that are particularly important. Use this indicator if your request fixes an RC bug.
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.
If you changed the package to address concerns, please send a follow-up email to your sponsorship request bug (nnn@bugs.debian.org) with the URL to the source package and the most recent changelog entries, as you did for 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 sponsorship requests. You do not need to be a Debian Developer to do so. We collect hints for reviewing packages on a dedicated webpage.
Please send any comments to nnn@bugs.debian.org, but do not send carbon copies to reviewers or the 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:
- moreinfo
- A reviewer has asked questions that need a response or has requested changes to be made. The package needs work before it can be uploaded.
- confirmed
- Somebody did a brief review of your package and it looks sane. It can still have (smaller) issues that need to be fixed before an upload.
- pending
-
Somebody is willing to look after the package until it is uploaded.
- wontfix
- The package has significant problems or cannot not be uploaded at all.
If you intend to take care of a sponsorship request until the related package is ready for upload, please consider setting yourself as the owner of the bug and tagging the bug as pending:
$ bts owner nnn me@example.com$ bts tag nnn +pending
Uploading Packages
After you upload a package, please close the bug report by sending an email to nnn-done@bugs.debian.org. Do not close RFS bugs in debian/changelog. The sponsor is responsible for solving the bug, not the supplier of the package or anyone related to the package itself.
Notes
Inactive sponsorship requests should be closed after a reasonable period of time. We consider this to be two weeks for requests tagged wontfix, six weeks for requests tagged moreinfo and six months for other tags, as appropriate. The same applies to uploaded packages for which the sponsor forgot to close the RFS bug.