Debian package sponsoring guidelines
This page presents what I expect when sponsoring a package. Be warned that I will be picky. Other sponsors may have different requirements.
I may spend a lot of time to review your package. I expect you to maintain it during its whole lifetime. If it hits a stable release, you will have to maintain it for at least three years. If you just seek to maintain any package, have a look at the list of Work-Needing and Prospective Packages instead of uploading some random package. We also have a lot of teams suffering from lack of people.
How to seek sponsorship#
- If there is a packaging team that would fit the subject of your package, you should request sponsorship through them. This is usually easier than traditional sponsorship. For example, if you are packaging a Python module, join the Debian Python Modules Team.
- Use mentors.debian.net and carefully read the
introduction. Publish your package through this
platform and use the provided RFS template. File a bug report
sponsorship-requestspseudo-package as explained on the site. You can only send me the request directly if I have sponsored one of your packages in the past.
- I only accept
3.0 (quilt)format packages.
- I don’t mind if you use CDBS or debhelper. However, if you
use debhelper, I expect you to use
dhcommand sequencer and use override targets. Also, I expect
debian/rulesto be as small as possible. Remove any unneeded comments and try to use files likes
- The package must be lintian-clean. Use
lintian -viIto check this. For anything whose severity is not “wishlist,”1 if you think that lintian is wrong, you can add an override.
- I expect a machine-readable
- All patches must contain meta-information as defined in the Patch Tagging Guidelines.
debian/watchfile is mandatory. If you cannot provide one for some reason, create it with a comment explaining why.
- The package must be built in a clean unstable chroot. Learn how to use cowbuilder or schroot for this purpose. It is quite easy. Really.
- Be careful with the description. The short description should tell exactly what the purpose of the package is. Avoid unneeded words. The long description can explain the features of the package and how it is different of other packages.
When iterating on your package, keep only one entry in the changelog. If this is a new package, don’t explain all the changes: we don’t care. If this is an update to a new package, explain all the changes since the last uploaded version.
For stuff reported as “wishlist,” some of them can be safely ignored if they are really minor. There is unfortunately no universal rule for this. I wish lintian didn’t report so many stuff at this level. For example, I consider that fixing spelling errors in upstream code is a waste of time. Don’t do that. ↩︎