Sponsoring requirements

I will refer to these guidelines by their identifiers in replies to RFS emails:

[ mentors ] [rfs] [ increment ] [ cdbs ] [ build ] [ watch ] [ lintian ] [ description ] [ join ] [ lang ] [ email ] [ break ] [ docs ] [ time ] [ native ]

What is a sponsor in Debian?

See http://www.debian.org/devel/join/newmaint#Sponsor

What do sponsors generally require?

See http://mentors.debian.net/cgi-bin/sponsor-intro

What other requirements may sponsors have?

What do I require?

Some of these are shamelessly cribbed from other sponsors.

Use mentors.debian.net - including RFS emails and uploads to the mentors repository. I do not sponsor packages from any other repositories.
A few pointers before you hit "Send" on that RFS email. (If you have already sent and been pointed here, resend it with the appropriate additions.)
1. Embellish, explain and put in the bug numbers!
  
  The bare RFS template is inadequate 95% of the time - it is not a fault of the template, it is a problem with insufficient detail for the specific package. No template can cover all packages and the maintainer needs to do the work and provide full details in the RFS.
  
  Note, this section from the Debian Mentors FAQ:
  
  Your message to -mentors is like an ad for your package. It's likely to be the only thing that prospective sponsors will judge your package on. You can have all the extra URLs you like in there where sponsors can get more information, but unless your initial message piques their interest, they'll never look at them.
  
  So, tell us what exactly your package does, and why it should be in Debian. If there is already a program that does a similar thing, say why your one is better. Put a little "hot spice" in there to hold people's interest. in other words, think like an advertising executive. Just remember to wash the slime off afterward. "
  
  Also take care when preparing the long description of the package itself - the description is a similar advert to the RFS email. Colin Walters has written some guidelines for package descriptions.
  
  Remember that your initial message still needs to include bug numbers and URL's once the sponsor does become interested.
2. Special cases:
  1. Packages removed from any existing distribution because such actions are not taken lightly.
  2. Packages that have been rejected from NEW previously.
  3. Packages that depend on any packages suffering from 'I' or 'II'.
  4. Packages already in Debian which have RC bugs that could lead to removal from testing and/or unstable if we were closer to a release.
  5. ITA - Intend to Adopt (orphaned package).
  6. Transfer of maintenance (or hijacking).
  Any package that meets any of these criteria needs substantial amounts of extra information in the RFS. It's hard to specify what this information should be, but the basic idea is that "special case" RFS packages (IMHO) must include full details of why the package is in that category.
  
  Removals need to include the bug numbers that caused removal and what has been done to prevent those issues recurring.
  
  Rejected packages need to include the reasons for rejection from NEW and what has been done to address the reasons for that rejection.
  
  If you are adopting an orphaned package, address the reasons why the package was orphaned, include the bug number of the bug that orphaned the package and what you can do to solve those issues.
  
  If you are proposing to take over maintenance of a package (or even more drastic, to hijack a package), I would expect to see specific references to attempts to contact the current maintainer and any response, any relevant bug numbers, links to any discussions on debian-devel and full details of the bugs or issues that make such an action necessary in the first place.
3. Reminders
  - Bug numbers are essential. There is no excuse for leaving them out, IMHO.
  - The long description should be included most of the time, epecially for an ITP because nobody in Debian knows what an ITP package is meant to do. Plus, ITP packages commonly include poorly constructed short and long descriptions. An RFS for an ITP can be based on the ITP itself.
  - Always make it absolutely clear if this is a new package or an existing package. Don't just quote the ITP number, say it is an ITP and give the number.
    - If not an ITP, it becomes imperative (IMHO) that the RFS includes specific information about the package and the background, including full disclosure of bugs that would be reopened and actions done to prevent the problems reappearing.
  - Check before you send. Maintainers who send multiple RFS emails often make basic mistakes where the repeat emails retain data from the first instead of being updated. Maintainers still send template-based RFS emails with no extra content.
Increment the package version for every upload to mentors.debian.net. Every time you fix something in the package to be sponsored, use dch -i to add a normal Debian entry to debian/changelog and detail what you have changed. Do not use artificial tags or version strings like ~rfs or unreleased - use only normal Debian version strings that would be suitable for upload without any further changes. This way, I do not need you to do a special pre-upload rebuild. I'll take care of including the original source and/or creating a single .changes file that includes all your changes. See my reasons.
If you use CDBS, use CDBS methods. (I like CDBS). Similarly, if you use debhelper, use debhelper commands throughout; do not resort to cp or mv hacks. Use the tools and use them properly.
If your package is NEW, you must have an ITP filed for at least a week before I'll upload it.
The package must build in a sane way. I use debuild and pdebuild.
Use a watch file - always - and make sure it works.
Do not assume your package is lintian clean - check it yourself and fix the lintian errors. Always ensure you are using the latest version of lintian - the version in Debian unstable. If you cannot fix the lintian error, ask on the debian-mentors mailing list before filing the RFS. Do not implement an override without checking on debian-mentors and filing the appropriate wishlist bug against lintian itself. Quote the bug number in a comment in the lintian override file.
Use sensible, understandable, package descriptions. Imagine you know nothing about the package or even the arena in which the package would normally be used.
You should be intending to join the Debian project, in some way, at some point in the future. I see sponsorship as a step to joining Debian, not an end in and of itself. You may not have a specific timeline for applying, but if you truly have no interest in ever joining Debian, stop now.

Sponsoring is an introduction to the Debian New Maintainer process and whether or not the maintainer is looking to join NM has no effect on the quality of packages at the start of sponsoring.

However, the likelihood of starting or being in the NM process itself is the perfect time to improve the quality of the current packages and all subsequent packages from that maintainer because the topics covered in NM are often best understood by being explained in the context of a package that is being actively sponsored at the same time.

I would rather sponsor someone prepared to go through NM for a couple of reasons:
- Demonstration of commitment to the package and to Debian.
- The NM process teaches a lot of things that would otherwise take up time on mentors or between maintainer and sponsor.
- Sponsoring eases the NM process itself so the NM queue is processed more quickly, benefiting everyone in the NM process.
- Someone in the NM queue will, eventually, become able to upload their own packages which not only gives them an incentive but gives me an escape route so that I'm not sponsoring that maintainer for ever and a day.
Use ${binary:Version} or ${source:Version}in place of the deprecated ${Source-Version} to make sure your package is binNMU safe.
I will not sponsor python, ruby, KDE or mono packages.

If your package uses PHP your RFS must include information on how the common security problems inherent in PHP have been overcome in your package.

If your package is written in C and uses either setuid or setgid to get root permissions, ensure that you understand the implications (noting that the actual code in that link may need updates to actually work - the explanation itself is clear enough.)
All communication by email only, preferably on the debian-mentors mailing list and wherever possible, signed with your GnuPG key. Do not pester me on IRC.
Use the newer features of the debian control scripts such as line breaks in Build-Depends and add Vcs-Browser:, Vcs-CVS: (or Vcs-SVN as appropriate) and Homepage: entries to debian/control.
You should be conversant with the relevant developers' documentation. That means knowing what Debian Policy and The Developers' Reference cover, and knowing where to find other information as required for the packages you want to maintain. I may refer to sections of Policy or the Developer Reference and I expect you to know how to find the section and apply that section to your package.

This also means that you must be familiar with the tools and scripts that are used to build, test and fix debian packages. e.g. devscripts, pbuilder, lintian, dpatch, quilt, cdbs and patchutils. Also consider deb-gview and meld. These tools will be used to test your package and you need to understand what these tools do and what problems can be identified by their usage.

For non-native packages (see the next section) try:
```
lsdiff -z $package_$version.diff.gz | grep -v "/debian/"
```
This command should produce no output - read the manpage and correlate that with Policy to work out why there should be no output for this command.
Do not abuse native packages - read my reasoning. Other sponsors may have different views but these are mine and I reserve the right to require that packages I sponsor must be aligned with my own requirements. Just as with any other requirement here, if you disagree you are free to find a different sponsor.
The software you intend to package must be suitable for inclusion in main. I don't have the time to do builds for contrib, and I don't have the inclination to support non-free software.
I can't guarantee how quickly your upload will be made. There is a fair bit of work to be done in sponsoring a package, especially for the first time, and there are plenty of other things that need to be done in this world. That being said, uploads will get done, and if your upload fixes RC bugs or is otherwise critically important, it will get a correspondingly higher priority in my work queue. Take a look at my main homepage for the kind of work I do.

Reasoning for the increment requirement

Trying to retain the same Debian version during the entire sponsorship process is prone to error and teaches bad habits. It is easier for everyone if every change during sponsorship gets a new Debian version, so if you need me to sponsor packages, each upload to mentors.debian.net must use a new Debian version. The simplest way to do that is with 'dch -i' and then a comment about what was fixed in this upload. This is how the Debian archive expects everyone to handle debian/changelog so this is what I should encourage during sponsoring.

This doesn't affect any other sponsor, it's just a change in how I prefer to sponsor.

Reasoning:

Using the same version all the time means that I have to either use a separate directory or remove all trace of the previous download before using dget -x and I would much prefer to have those other versions around - if only to ensure that I know which problems are meant to have been fixed without relying on my memory! :-)
Using separate versions also allows easy use of debdiff and 'interdiff -z' which are invaluable for checking exactly which files have been changed between versions.
Using different versions also means you usually only upload the .orig.tar.gz once so that makes it easier for slow or problematic connections.

Full text: http://lists.debian.org/debian-mentors/2007/07/msg00249.html.

@ Debian

Sponsoring requirements

Embellish, explain and put in the bug numbers!

Special cases:

Reminders

Reasoning for the increment requirement