+New maintainers usually have certain difficulties creating Debian packages —
+this is quite understandable. They will do mistakes. That's why sponsoring
+a brand new package into Debian requires a thorough review of the Debian
+packaging. Sometimes several iterations will be needed until the package
+is good enough to be uploaded to Debian. Thus being a sponsor implies being
+a mentor.
+</para>
+<para>
+Don't ever sponsor a new package without reviewing it. The review
+of new packages done by ftpmasters mainly ensures that the software
+is really free. Of course, it happens that they stumble on packaging
+problems but they really should not. It's your task to ensure that
+the uploaded package complies with the Debian Free Software Guidelines and
+is of good quality.
+</para>
+<para>
+Building the package and testing the software is part of the review, but
+it's also not enough. The rest of this section contains a non-exhaustive
+list of points to check in your review.
+<footnote>
+<para>
+You can find more checks in the wiki where several developers share their own
+<ulink url="http://wiki.debian.org/SponsorChecklist">sponsorship checklists</ulink>.
+</para>
+</footnote>
+</para>
+<itemizedlist>
+<listitem>
+<para>Verify that the upstream tarball provided is the same that has been
+distributed by the upstream author (when the sources are repackaged for
+Debian, generate the modified tarball yourself).</para>
+</listitem>
+<listitem>
+<para>Run <command>lintian</command> (see <xref linkend="lintian"/>). It will catch many common
+problems. Be sure to verify that any <command>lintian</command> overrides setup by the
+maintainer is fully justified.</para>
+</listitem>
+<listitem>
+<para>Run <command>licensecheck</command> (part of <xref linkend="devscripts"/>) and verify that
+<filename>debian/copyright</filename> seems correct and complete. Look for
+license problems (like files with “All rights reserved”
+headers, or with a non-DFSG compliant license). <command>grep -ri</command>
+is your friend for this task.</para>
+</listitem>
+<listitem>
+<para>Build the package with <command>pbuilder</command> (or any similar tool, see <xref
+linkend="pbuilder"/>) to ensure that the build-dependencies are
+complete.</para>
+</listitem>
+<listitem>
+<para>Proofread <filename>debian/control</filename>: does it follow the
+best practices (see <xref linkend="bpp-debian-control"/>)? Are the dependencies
+complete?</para>
+</listitem>
+<listitem>
+<para>Proofread <filename>debian/rules</filename>: does it follow the
+best practices (see <xref linkend="bpp-debian-rules"/>)? Do you see some
+possible improvements?</para>
+</listitem>
+<listitem>
+<para>Proofread the maintainer scripts (<filename>preinst</filename>,
+<filename>postinst</filename>, <filename>prerm</filename>,
+<filename>postrm</filename>, <filename>config</filename>): will the
+<filename>preinst</filename>/<filename>postrm</filename> work when the dependencies are not
+installed? Are all the scripts idempotent (i.e. can you run them multiple
+times without consequences)?</para>
+</listitem>
+<listitem>
+<para>Review any change to upstream files (either in <filename>.diff.gz</filename>, or in
+<filename>debian/patches/</filename> or directly embedded in the <filename>debian</filename>
+tarball for binary files). Are they justified? Are they properly
+documented (with <ulink url="&url-dep3;">DEP-3</ulink> for patches)?</para>
+</listitem>
+<listitem>
+<para>For every file, ask yourself why the file is there and whether it's
+the right way to achieve the desired result. Is the maintainer following
+the best packaging practices (see <xref
+linkend="best-pkging-practices"/>)?</para>
+</listitem>
+<listitem>
+<para>Build the packages, install them and try the software. Ensure you can
+remove and purge the packages. Maybe test them with <command>piuparts</command>.