[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Checklist for Package Sponsors

To developers who sponsor packages (and sponsees), a checklist of
things to verify before sponsoring packages has been created, and is
included below.

While the checklist is not exhaustive, it does underline some of the
comon problems found in sponsored packages which are sometimes not


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)? If not, is the maintainer capable of
       handling upstream problems? Are you?

  Determine if the package can actually get into Debian

     * Does the package conform to all the items in the ftpmasters
       REJECT-FAQ document?

  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

     * 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


     * 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?


     * Are the rules sane?

     * Are all of the targets there?

     * Are they using existing tools correctly? (debhelper? cdbs? quilt?

     * Have they removed (or commented out) useless debhelper calls?

     * Does the maintainer understand what their rules file does?


     * Are the changes to the packaging described?

     * Are ITP/ITA bugs closed?

     * Have the comments in the ITP/ITA bug been addressed?

     * Are existing bugs in the package fixed?

     * If a security issue is mentioned is a CVE id mentioned too?

     * Are bugs closed by the upstream code just closed or are the fixes
       described too?


     * Is the package lintian/linda clean?

     * Does it build in a buildd pbuilder chroot?

     * Does it build correctly a second time after cleaning?

     * Does the resulting package install correctly?

     * Does it uninstall cleanly?

     * Does it pass puiparts tests?

     * 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?

     * If upstream provides md5sum/shasums for the source, does the signature
       still match?

     * Are you building against Debian distributed libraries and not against
       internal copies?

     * Are there potential security issues? (Daemons, tempfile
       vulnerabilities, setuid binaries?)

     * If building against internal code copies, has the maintainer notified
       the security team that there are embedded code copies?

Don Armstrong

Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
 -- Matt Welsh

http://www.donarmstrong.com              http://rzlab.ucr.edu

Reply to: