Team-Maintainence documentation; #410159

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

diff --git a/debian/changelog b/debian/changelog
index fa3a360dd22c05ae6070c91054207429f3723a68..d4505cba1483e0ee9e724568a944413601b19d06 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,8 @@ developers-reference (3.3.9) unstable; urgency=low
   * Add XS-Vcs-*. Thanks to Stefano Zacchiroli. Closes: #391023
   * Small brushup to debconf description. Thanks, Thomas Huriaux.
     Closes: #401415
+  * Document Team-Maintainence better. Thanks, Lucas Nussbaum.
+    Closes: #410159
 
  -- Andreas Barth <aba@not.so.argh.org>  Sat, 16 Jun 2007 11:41:41 -0600
 

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 36baf1d664af17633e5a81945c76d7366b0f4750..a09903cfd840dcdd2035f96644ebf1d09a5a1873 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.326 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -3314,7 +3314,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 +3333,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">