removal wiki page. #412757

[developers-reference.git] / developers-reference.sgml

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 36baf1d664af17633e5a81945c76d7366b0f4750..a49858ce435e7117da74e0271a198ed45bdcc71e 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -7,7 +7,7 @@
   <!ENTITY % dynamicdata  SYSTEM "dynamic.ent" > %dynamicdata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.325 $">
+  <!ENTITY cvs-rev "$Revision: 1.327 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -2581,6 +2581,9 @@ Usually you only ask for the removal of a package maintained by yourself.
 If you want to remove another package, you have to get the approval
 of its maintainer.
        <p>
+Further information relating to these and other package removal related
+topics may be found at <url id="http://wiki.debian.org/ftpmaster_Removals">.
+       <p>
 If in doubt concerning whether a package is disposable, email
 &email-debian-devel; asking for opinions.  Also of interest is the
 <prgn>apt-cache</prgn> program from the <package>apt</package>
@@ -3314,7 +3317,8 @@ quite easy:
 Setup the co-maintainer with access to the sources you build the
 package from.  Generally this implies you are using a network-capable
 version control system, such as <prgn>CVS</prgn> or
-<prgn>Subversion</prgn>.</p>
+<prgn>Subversion</prgn>. Alioth (see <ref id="alioth">) provides such
+tools, amongst others.</p>
             </item>
             <item>
               <p>
@@ -3332,9 +3336,32 @@ Using the PTS (<ref id="pkg-tracking-system">), the co-maintainers
 should subscribe themselves to the appropriate source package.</p>
             </item>
           </list></p>
-       <p>
-Collaborative maintenance can often be further eased by the use of
-tools on Alioth (see <ref id="alioth">).
+              <p>
+Another form of collaborative maintenance is team maintenance, which is
+recommended if you maintain several packages with the same group of
+developers. In that case, the Maintainer and Uploaders field of each
+package must be managed with care. It is recommended to choose between
+one of the two following schemes:
+               <enumlist>
+                <item>
+              <p>
+Put the team member mainly responsible for the package in the Maintainer
+field. In the Uploaders, put the mailing list address, and the team members
+who care for the package.
+                </item>
+                <item>
+              <p>
+Put the mailing list address in the Maintainer field. In the Uploaders
+field, put the team members who care for the package.
+In this case, you must make sure the mailing list accept bug reports
+without any human interaction (like moderation for non-subscribers).
+                </item>
+               </enumlist>
+              <p>
+In any case, it is a bad idea to automatically put all team members in
+the Uploaders field. It clutters the Developer's Package Overview listing
+(see <ref id="ddpo">) with packages one doesn't really care for, and
+creates a false sense of good maintenance.
       </sect>
 
     <sect id="testing">