OBSOLETE!

Please see MainInclusionProcess for how this works now.

DO NOT USE THIS ANY MORE!

Main Inclusion Report for sourcepackage

Note: when writing a report this template should be vigorously edited; as a rule of thumb, every individual point should be replaced with a description of the actual situation in the package in question. The purpose of the report is to convey information to the reviewer, so there is no problem with varying the text in the bullet items, or with adding additional information.

Please be informative, and in particular be thorough in investigating and explaining any weaknesses and problems with the package. The purpose of the report is to show to the reviewer that the package has been properly investigated, and to give the reviewer the information from that investigation, for their decision.

Requirements

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/s/sourcepackage; available for all supported architectures or some subset ?

2. Rationale:

   • Why is this package needed? What feature(s) does it add? Does upstream expect it? Plain text description of expected use
   • Build dependency of ...

3. Security:

   • CVE entries: ...

   • Secunia history: ...

   • Any binaries running as root or suid/sgid ? Any daemons ?
   • Network activity: does it open any port ? Does it handle incoming network data ?
   • Does it directly (not through a library) process binary (video, audio, etc) or structured (PDF, etc) data ?
   • Any source code review performed ? (The approver will do a quick and shallow check.)

4. Quality assurance:

   • In what situations does the package not work out of the box without configuration ?
   • Does the package ask any debconf questions higher than priority 'medium' ?

   • Debian bugs: (mention any that are particularly relevant, and any showstoppers)

   • Maintenance in Debian is frenetic/vigorous/calm/dead ?

   • Upstream is frenetic/vigorous/calm/dead ?

   • Upstream bug tracker: (mention any particularly relevant or critical)

   • Hardware: Does this package deal with hardware and if so how exotic is it ?
   • Is there a test suite in the upstream source or packaging ? Is it enabled to run in the build ?

5. UI standards:

   • User-visible strings are internationalized using standard gettext system ?
   • Package with translatable strings builds a PO template during package build ?
   • End-user applications ship a desktop file ?

6. Standards compliance:

   • FHS, Debian Policy compliance ?

   • Packaging system (debhelper/cdbs/dbs) ? Patch system ? Any packaging oddities ?

7. Dependencies:

   • ...
   • Are these all in main ?

8. Maintenance:

   • How much maintenance is this package likely to need ? (Simple packages may largely take care of themselves; complex packages will need dedicated developers paying attention to them.)
   • Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ?
   • Who is the package bug contact in Ubuntu? (Needs one if its a nontrivial package which does not fully maintain itself through Debian)

9. Background information:

   • The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
   • What do upstream call this software ? Has it had different names in the past ?

10. Internationalization:

    • Are graphical applications translatable? Do they support gettext?

Reviewers

MIR bug: https://launchpad.net/bugs/BUGNUMBER

The author of this report should put their name here; reviewers will add comments etc. too