Sponsor Checklist
Considering some of the question marks that have come up regarding
sponsored packages, I thought I'd create a little checklist based on
some of the things that I've seen go wrong.
I thought I'd bounce it through you all before I sent it on to -devel.
http://wiki.debian.org/SponsorChecklist
Feel free to make changes on the wiki; I've duplicated it here just
for fun:
Checklist for Package Sponsors
The checklist below is not exhaustive; you should be applying all of
the normal checks you do to your own packages in addition to these.
(If there are additional checks that you think should be added, feel
free to add them.)
Determine if the package actually belongs in Debian
* Is there a significant use case for the package?
* Are there pre-existing packages that do a better job?
* Would you use the package?
* Does the maintainer use the package?
* What is the maturity level of the upstream codebase?
* Is upstream active (alive)?
Determine if the maintainer can actually maintain the package
* What is the skill level of the maintainer?
* Are they familiar with the package and its languages?
* How active are they?
* Do they have existing packages?
* How do they interact with users? [Check out their existing bugs.]
Determine if you can back up the maintainer
* Is the package one that you are comfortable maintaining if the
maintainer disappears?
* Do you have time to assist the maintainer if they get stuck?
Make sure that the package can be distributed by Debian
* Does debian/copyright list all of the copyrights of portions of the
code?
* Are all pieces licensed under licenses that Debian can distribute?
* Does the proposed section (main, contrib, non-free) match the
license?
* Are there significant patents which the work infringes which are
known to be enforced?
Make sure that the packaging is up to par
control
* Is the description good?
* Have they sent an ITP with the description to -devel? [Have they
incorporated any comments?]
* Are the dependencies correct? Are there missing recommends?
Suggests?
rules
* Are the rules sane?
* Are all of the targets there?
* Are they using the extant tools correctly?
* Have they removed (or commented out) useless debhelper calls?
* Does the maintainer understand what their rules file does?
changelog
* Are the changes to the packaging described?
* Are ITP bugs closed?
* Are existing bugs in the package fixed?
general
* Is the package lintian/linda clean?
* Does it build in a buildd pbuilder chroot?
* Do the resultant packages work? Have you used them?
* Does the package contain what it's supposed to contain?
* Does the .diff.gz look sane?
* Is the upstream source pristine?
Check out the upstream codebase
* Is the upstream source sane?
* Are you building against Debian distributed libraries or internal
copies?
* Are there potential security issues? (Daemons, tempfile
vulnerabilities, setuid binaries?)
Don Armstrong
--
[A] theory is falsifiable [(and therefore scientific) only] if the
class of its potential falsifiers is not empty.
-- Sir Karl Popper _The Logic of Scientific Discovery_ §21
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: