Neil Williams @ Debian
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 ]
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.)
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.
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.
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.cp or mv hacks. Use the
tools and use them properly.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:
${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.)
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.
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:
Full text: http://lists.debian.org/debian-mentors/2007/07/msg00249.html.