Add recommendations to re-introduce packages. Thanks to Paul Wise for the patch....

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@9362 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/common.ent b/common.ent
index 9337c688f234863a6318fbc89d796e0afe38a479..20710021747d5fb5eacd16d173f11531e1ab22cb 100644 (file)
--- a/common.ent
+++ b/common.ent
@@ -28,6 +28,7 @@
 <!ENTITY www-debian-org "www.debian.org">
 <!ENTITY ftp-debian-org "ftp.debian.org">
 <!ENTITY release-debian-org "release.debian.org">
+<!ENTITY snap-debian-org "snapshot.debian.org">
 <!ENTITY lists-host "lists.debian.org">
 <!ENTITY archive-host "archive.debian.org">
 <!ENTITY keyserver-host "keyring.debian.org">

diff --git a/debian/changelog b/debian/changelog
index 9cbfe41c8c87b3610fbcf8203216b9426cf0be99..73b5d5eb7c435c33b3d199cfef73afa311572f00 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+developers-reference (3.4.10) UNRELEASED; urgency=low
+
+  * Add recommendations to re-introduce packages. Thanks to Paul Wise for the
+    patch. Closes: #685039
+
+ -- Raphaël Hertzog <hertzog@debian.org>  Mon, 17 Sep 2012 17:20:49 +0200
+
 developers-reference (3.4.9) unstable; urgency=low
 
   * Team upload.

diff --git a/pkgs.dbk b/pkgs.dbk
index 8e64063dff62c02225baec398d5063458b15ea15..07b3f85b6d3932a3d02736f7808611417bec4574 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1238,7 +1238,7 @@ on <literal>&ftp-master-host;</literal>.
 </section>
 
 <section id="archive-manip">
-<title>Moving, removing, renaming, adopting, and orphaning packages</title>
+<title>Moving, removing, renaming, orphaning, adopting, and reintroducing packages</title>
 <para>
 Some archive manipulation operations are not automated in the Debian upload
 process.  These procedures should be manually followed by maintainers.  This
@@ -1486,6 +1486,54 @@ they will continue to receive the bugs during that time.
 </para>
 </section>
 
+<section id="reintroducing-pkgs">
+<title>Reintroducing packages</title>
+<para>
+Packages are often removed due to release-critical bugs, absent maintainers,
+too few users or poor quality in general. While the process of reintroduction
+is similar to the initial packaging process, you can avoid some pitfalls by
+doing some historical research first.
+</para>
+<para>
+You should check why the package was removed in the first place. This
+information can be found in the removal item in the news section of the PTS
+page for the package or by browsing the log of
+<ulink url="http://&ftp-master-host;/#removed">removals</ulink>.
+The removal bug will tell you why the package was removed and will give some
+indication of what you will need to work on in order to reintroduce the package.
+It may indicate that the best way forward is to switch to some other piece of
+software instead of reintroducing the package.
+</para>
+<para>
+It may be appropriate to contact the former maintainers to find out if
+they are working on reintroducing the package, interested in co-maintaining
+the package or interested in sponsoring the package if needed.
+</para>
+<para>
+You should do all the things required before introducing new packages
+(<xref linkend="newpackage"/>).
+</para>
+<para>
+You should base your work on the latest packaging available that is suitable.
+That might be the latest version from <literal>unstable</literal>, which will
+still be present in the <ulink url="&snap-debian-org;">snapshot archive</ulink>.
+</para>
+<para>
+The version control system used by the previous maintainer might contain useful
+changes, so it might be a good idea to have a look there.  Check if the control
+file of the previous package contained any headers linking to the version
+control system for the package and if it still exists.
+</para>
+<para>
+Package removals from unstable (not testing, stable or oldstable) trigger the
+closing of all bugs related to the package. You should look through all the
+closed bugs (including archived bugs) and unarchive and reopen any that were
+closed in a version ending in <literal>+rm</literal> and still apply. Any that
+no longer apply should be marked as fixed in the correct version if that is
+known.
+</para>
+</section>
+
 </section>
 
 <section id="porting">