Differences between revisions 1 and 40 (spanning 39 versions)
Revision 1 as of 2007-07-30 18:30:20
Size: 1589
Editor: DonArmstrong
Comment:
Revision 40 as of 2016-05-23 15:24:44
Size: 5126
Editor: PaulWise
Comment: Petter Reinholdtsen's guidelines
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#language en
Line 2: Line 3:
=== Checklist for Package Sponsors === <<TableOfContents(3)>>

= Checklist for Package Sponsors =
Line 7: Line 10:
(If there are additional checks that you think should be added, feel
free to add them.)

== Checklists from individual DDs/groups ==

 * [[PaulWise/Standards|Paul Wise]]
 * [[http://people.debian.org/~codehelp/#sponsor|Neil Williams]]
 * [[http://people.debian.org/~piotr/sponsor|Piotr Ożarowski]]
 * [[http://people.debian.org/~madcoder/sponsor.html|Pierre Habouzit]]
 * [[http://people.debian.org/~mjr/sponsor-apogi.html|MJ Ray]]
 * [[http://people.debian.org/~neilm/sponsorship.html|Neil McGovern]]
 * [[http://people.debian.org/~daniel/documents/sponsoring.html|Daniel Baumann]]
 * [[http://workaround.org/debian-package-sponsoring|Christoph Haas]]
 * [[http://people.debian.org/~nijel/sponsoring/|Michal Čihař]]
 * [[http://raphaelhertzog.com/2011/02/10/best-practices-when-sponsoring-debian-packages/|Raphaël Hertzog]]
 * [[http://www.hungry.com/~pere/debian-sponsoring.html|Petter Reinholdtsen]]
 * [[Games/Checklist|Debian games team]]
 * [[KilianKrause]]
 * [[LucaFalavigna/NEWChecklist|Checklist for NEW]], [[http://ftp-master.debian.org/REJECT-FAQ.html|REJECT-FAQ]]
 * [[http://people.debian.org/~paultag/sponsorship/|Paul Tagliamonte]]
 * [[http://people.debian.org/~abe/sponsoring/|Axel Beckert]]
 * [[https://wiki.debian.org/Teams/Ruby/Packaging#Requesting_Sponsorship|Debian Ruby Team]]
 * [[DanielKahnGillmor/preferred_packaging|Daniel Kahn Gillmor]]
Line 10: Line 36:
* 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)?
 * 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?
Line 17: Line 43:
== Determine if the maintainer can actually maintain the package ==  == Determine if the package can actually get into Debian ==
Line 19: Line 45:
* 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?
 * Does the package conform to all the items in the ftpmasters [[http://ftp-master.debian.org/REJECT-FAQ.html|REJECT-FAQ]] and [[LucaFalavigna/NEWChecklist|NEWChecklist]] documents?

== 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?
 * Do they have too many packages or too many bugs?
 * How do they interact with users? [Check out their existing bugs.]
Line 27: Line 59:
* Is the package one that you are comfortable maintaining if the
 
maintainer disappears?
 * Is the package one that you are comfortable maintaining if the maintainer disappears?
Line 30: Line 61:
* Do you have time to assist the maintainer if they get stuck?  * Do you have time to assist the maintainer if they get stuck?
Line 36: Line 67:
* Does debian/copyright list all of the copyrights of portions of the
 
code?
 * Does debian/copyright list all of the copyrights of portions of the code?
Line 39: Line 69:
* Are all pieces licensed under licenses that Debian can distribute?  * Are all pieces licensed under licenses that Debian can distribute?
Line 41: Line 71:
* Does the proposed section (main, contrib, non-free) match the
 
license?
 * Does the proposed section (main, contrib, non-free) match the license?
Line 44: Line 73:
* Are there significant patents which the work infringes which are
 
known to be enforced?
 
 * Are there significant patents which the work infringes which are known to be enforced?
Line 49: Line 77:
= control = === control ===
Line 51: Line 79:
* Is the description good?  * Is the description good?
Line 53: Line 81:
* Have they sent an ITP with the description to -devel? [Have they
 
incorporated any comments?]
 * Have they sent an ITP with the description to -devel? [Have they incorporated any comments?]
Line 56: Line 83:
*  * Are the dependencies correct? Are there missing recommends? Suggests?
Line 58: Line 85:
=== rules ===
Line 59: Line 87:
CategoryDeveloper  * Are the rules sane?
 * Are all of the targets there?
 * Are they using existing tools correctly? (debhelper? cdbs? quilt? etc?)
 * 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/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?

=== general ===

 * Is the package lintian 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 piuparts 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?

CategoryDeveloper CategoryDeveloper

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.)

Checklists from individual DDs/groups

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

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?
  • Do they have too many packages or too many bugs?
  • 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 existing tools correctly? (debhelper? cdbs? quilt? etc?)
  • 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/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?

general

  • Is the package lintian 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 piuparts 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?

CategoryDeveloper CategoryDeveloper