Checklist for Debian's NEW Queue

Introduction

NEW checking is about three things. In order of priority:

• trying to keep the archive legal;
• trying to keep the package namespace sane;
• trying to reduce the number of bugs in Debian.

This is a checklist of major points to check while processing the NEW queue. It is not meant to be an exhaustive reference, but it gives a quick overview of the most important points FTP Team will look after; developers should check these points prior of uploading a package in NEW to save time for both parties. Visit this list from time to time, as we may change points or add new ones.

• Is it worth including the package in the archive?
  • Is it maintained upstream?
  • Is it buggy, or does it represent a security threat?
  • Can the same features be provided by other source packages?
  • Is it really useful?
  • Is its content "little" enought to be included in another package?
• Is source name valid?
  • Does it respect naming convention of similar packages?
  • Does it replace other software in the archive?
• Is version valid?
• Is Distribution field set correctly?
  • Is upload intended for a different distribution than the one listed in Distribution field?
• Are dependencies and build-dependencies satisfied?
• Are descriptions accurate and exaustive?
• Are binary package names valid?
  • Do they respect naming convention of similar packages?
  • Do they replace other software in the archive?
• Are binary packages not empty?
• Are binary architectures valid?
• Do files in binary packages respect FHS?
• Is package lintian-free for noteworthy errors or warnings?
• Is source code DFSG-free?
  • Does it contain binaries of any kind without corresponding sources?
  • Does it provide PDF files without corresponding sources?
  • Does it contain compressed code without corresponding plain-text version?
• Is copyright file accurate?
  • Does copyright file mention correct copyright holders list?
  • Does copyright file mention every license for every file in the source code?
  • Does it comply with machine readable copyright file, if applicable?
• Is the package QA safe?
  • Is source code of good quality?
  • Does it contain convenience copy of system libraries?
  • Does it violate Reject FAQ listed below?
  • Is debian/control valid and complete?
  • Is debian/rules valid and complete?
  • Are maintainer scripts valid and complete?
• Are NEW overrides correct?

• Is there a valid reason to provide a new binary package?
• Is version valid?
• Is Distribution field set correctly?
  • Is upload intended for a different distribution than the one listed in Distribution field?
• Are dependencies and build-dependencies satisfied?
• Are descriptions accurate and exaustive?
• Is binary package names valid?
  • Does it respect naming convention of similar packages?
  • Does it replace other software in the archive?
• Is binary packages not empty?
• Are binary architectures valid?
• Do files in binary packages respect FHS?
• Is package lintian-free for noteworthy errors or warnings?
• Is source code DFSG-free?
  • Does it contain binaries of any kind without corresponding sources?
  • Does it provide PDF files without corresponding sources?
  • Does it contain compressed code without corresponding plain-text version?
• Is copyright file accurate?
  • Does copyright file mention correct copyright holders list?
  • Does copyright file mention every license for every file in the source code?
  • Does it comply with machine readable copyright file, if applicable?
• Is the package QA safe?
  • Does it list proper Conflicts/Breaks/Replaces fields?
  • Does it violate Reject FAQ listed below?
• Are NEW overrides correct?
• Is Release Team aware of library transition introduced with the new binary?

Last modified: Sat Jul 13 11:27:31 UTC 2013