From 11ac4b798f120a7d699065a6281fc003c254b9ff Mon Sep 17 00:00:00 2001
From: aph <aph@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Date: Fri, 14 Jun 2002 06:19:25 +0000
Subject: [PATCH] populate Sec "Collaborative maintenance"

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1714 313b444b-1b9f-4f58-a734-7bb04f332e8d
---
 developers-reference.sgml | 49 ++++++++++++++++++++++++++++++++-------
 1 file changed, 40 insertions(+), 9 deletions(-)

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 4f13608..cb022f7 100644
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.111 $">
+  <!entity cvs-rev "$Revision: 1.112 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -2228,12 +2228,43 @@ headers for cross-compiling in a way similar to
 enhanced to support cross-compiling.
 
 
-    <sect id="collaborative-maint">Collaborative maintenance
-      <p>
-&FIXME; Speak about Uploaders: field, about the intelligent use
-of the PTS. Insist that it's a "must have" for base and standard
-packages.
-
+    <sect id="collaborative-maint">
+        <heading>Collaborative maintenance</heading>
+        <p>
+"Collaborative maintenance" is a term describing the sharing of Debian
+package maintenance duties by several people.  This collaboration is
+almost a good idea, since it generally results in higher quality and
+faster bug fix turnaround time.  It is strongly recommended that
+packages in which a priority of <tt>Standard</tt> or which are part of
+the base set have co-maintainers.</p>
+        <p>
+Generally there is a primary maintainer and one or more
+co-maintainers.  The primary maintainer is the whose name is listed in
+the <tt>Maintainer</tt> field of the <file>debian/control</file> file.
+Co-maintainers are all the other maintainers.</p>
+        <p>
+In its most basic form, the process of adding a new co-maintainer is
+quite easy:<list>
+            <item>
+              <p>
+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>
+            </item>
+            <item>
+              <p>
+Add the co-maintainer's correct maintainer name and address to the
+<tt>Uploaders</tt> field in the global part of the
+<file>debian/control</file> file.</p>
+            </item>
+            <item>
+              <p>
+Using the PTS (<ref id="pkg-tracking-system">), the co-maintainers
+should subscribe themselves to the appropriate source package.</p>
+            </item>
+          </list></p>
+      </sect>
 
     <sect id="archive-manip">
       <heading>Moving, Removing, Renaming, Adopting, and Orphaning
@@ -2727,13 +2758,13 @@ source package.
 	<p>
 Debconf is a configuration management system, it is used by all the
 various packaging scripts (postinst mainly) to request feedback from the
-user in the intent to configure the package. Direct user interactions
+user concerning how to configure the package. Direct user interactions
 must now be avoided in favor of debconf interaction. This will enable
 non-interactive installations in the future.
 	<p>
 Debconf is a great tool but it is often badly used ... many common mistakes
 are listed in the <manref name="debconf-devel" section="8"> man page. 
-It is something that you must have read if you decide to use debconf.
+It is something that you must read if you decide to use debconf.
 
 <!--
 	<sect1 id="custom-config-files">Custom configuration files
-- 
2.30.2