Neil Williams @ Debian
For my reasons, see: http://lists.debian.org/debian-mentors/2009/08/msg00055.html
[ break ] [ build ] [ cdbs ] [ copyright ] [ debconf ] [ debtags ] [ description ] [ docs ] [ email ] [ generality ] [ homepage ] [ increment ] [ join ] [ lang ] [ legal ] [ lintian ] [ manpages ] [ mentors ] [ sponsors ] [ time ] [ watch ]
There are large differences between requirements for different sponsors.
Feel free to use the guidelines that suit you and select your sponsor appropriately
These are my own requirements and have no bearing on the requirements of other sponsors. This page is not authoritative in any way, it is not a HowTo or a tutorial and is offered on the simple basis that it might be useful to other maintainers and for other packages. Certain points are clearly personal to me and my former sponsoring only.
By all means use the page for your own work, but please don't make it into something it is not or recommend it for purposes that are beyond the scope of the actual document. Some elements are already lintian tests, some extend lintian tests and some are entirely my own preference. Use your own judgement when using this page with packages that I am not actually sponsoring.
Some of these are shamelessly cribbed from other sponsors.
This includes RFS emails and uploads to the mentors repository. I do not sponsor packages from any other repositories or websites.
Increment the package version
Increment the 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
The ITP must have been filed for at least a week before I'll upload it.
The ITP must be fully completed and I expect each RFS to be complete also, using the ITP template only as a start and adding content of your own.
If you use debconf, the templates need to be translated.
Sponsoring takes time so before you introduce any new or updated debconf templates into Debian, I will ask you to use po-debconf to call for translations for the debconf templates and specify a deadline of at least 10 days, preferably about 2-3 weeks. Include a statement to this effect in your RFS so that sponsors know that the upload must wait until the translators have had a chance to submit translations. The call for translations itself should be made only once a sponsor has agreed to review the package, so I will review your debconf templates for English grammar and vocabulary and let you know when the email should be sent out. Ensure you abide by all the other debconf requirements as well.
If your package is NEW, the call for translations will request translators to send translations directly to you as the BTS will not have a listing for your package until after the sponsored upload to Debian.
Even when templates do not change, I expect to see some evidence that new translations are being sought on a fairly regular basis (at least annually, preferably bi-annually) and that incomplete translations are being pursued via the relevant language team and/or debian-i18n. If the debconf templates have not changed, I expect the RFS to include a statement to this effect.
If your package uses gettext (with or without using debconf itself), consider asking for translations for the package strings as well - po-debconf will identify the existing translation support and not ask for translations (or send email to the Last-Translator) if the translation is up to date. Note that packages that are part of established l10n teams like GNOME or KDE can easily use that support. The extra step is intended for independent packages that would otherwise not be widely translated.
The package must build in a sane way.
I use debuild and pdebuild. If appropriate, I'll also probably cross-build your package and feedback on changes that are needed for such support. I don't expect you to try to cross-build your package but a sane build method is essential to such testing.
No excuses, always use a watch file - and make sure it works.
Do not assume your package is lintian clean
Check it yourself using the version of lintian in Debian unstable and fix the lintian errors.
I do not require that lintian is used in --pedantic mode. If --pedantic provides useful assistance for something that should be fixed anyway, I will use it. However, if I use --pedantic, I will filter out the messages that are likely to be unreliable for the package concerned.
If there are lintian errors or warnings, without using --pedantic, you need to fix them. This is not optional - do not abuse lintian override files and do not use override files for --pedantic.
If there are bugs in lintian then file bugs against lintian and reference them in the override files and include or attach the override files to your RFS. Overrides without bug numbers are worse than retaining the unfixed lintian warning or error.
As part of lintian support, I appear to need to restate the need for manpages. Lintian warnings about missing manpages are absolutely and wholly unacceptable. Write the manpages - no excuses. Write all the missing manpages and make sure each one covers all the commands and options that are available for the binaries concerned. For non-native packages, ensure you submit the manpages upstream and work with upstream to implement a method of keeping the manpages updated (e.g. docbook-xsl etc.). Include a link to the upstream bug report, or other such (public) notification concerning the manpages, in your RFS.
I cannot overstate the importance of this criterion - nothing is more indicative of a lazy maintainer than trivially fixable lintian warnings and I consider all missing manpages as trivially fixable. I will not sponsor packages where I consider the maintainer to be lazy. I don't care what you think about manpages, write them and ensure they are all complete.
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
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.
Use ${binary:Version}
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, Java, KDE or mono packages.
I will not sponsor python, ruby, Java, KDE or mono packages.
Make sure that your RFS email to the mentors mailing list contains all necessary information, this includes listings for:
ITP or RFS content that does not detail the programming language or does not include appropriate Licence information will be ignored.
All communication by email only
Yes, email only - preferably on the debian-mentors mailing list and wherever possible, signed with your GnuPG key. Pestering me on IRC is likely to end with you needing a new sponsor (or at best being ignored).
I'm always busy, I have always got lots of stuff that needs doing before your upload, so ask me nicely and I'll look at moving you up the ToDo list.
See the section on languages for requirements on the contents of your RFS email to the mentors mailing list.
If the upload closes a bug that is not an ITP bug, the full title of that bug should be included in the RFS along with the current severity of that bug.
Use the newer features of the debian control scripts
Features such as line breaks in Build-Depends and add XS-X-Vcs-Browser, XS-X-Vcs-CVS and Homepage entries have been added for good reasons - use them.
You must 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.
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.
Check the licenses
Use licensecheck -r * and fix the problems. Ensure that all the licenses specified in the output are detailed in debian/copyright. (If you have built the package in the current directory, you can ignore any problems with config.h.)
See also the section on languages for requirements on the contents of your RFS email to the mentors mailing list.
debian/copyright format - the machine-operable format on the Debian wiki http://wiki.debian.org/Proposals/CopyrightFormat has grown into a behemoth that actually makes debian/copyright harder to read as a human, as far as I am concerned. Whilst trying to work with the format and discussing the implications with other sponsors, I've become unhappy with the current version as overly complicated and hard to understand. As such, I will sponsor packages where debian/copyright is still readable and understandable by a human, more specifically, me.
See one of my own copyright files http://packages.debian.org/changelogs/pool/main/t/tslib/current/copyright as an example of the possible middle-ground between the free text format and the full machine-operable version.
Use the Homepage field
Use Homepage in debian/control, do not include a URL in the long description. All uploads of non-native packages must include the Homepage field. If no homepage really exists, explain that in your RFS.
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.
Any bugs closed in the intervening changelog entries are easily collated into the final .changes file that I actually sign and then upload, using the -v option to dpkg-buildpackage. The process is manual but then it's my requirement, my burden. To try it for yourself, just pass the version of the last Debian upload (or blank for NEW) in the argument to -v.
Reasoning:
Full text: http://lists.debian.org/debian-mentors/2007/07/msg00249.html.