X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=7adb92514e9fde259d8b3e876de5d3ffdbbae8a8;hb=6a0a618b63bc76eab2b6bcab058d714b0c3e8291;hp=ba2a9b7f74a1b285a483d96f87f4808708672af1;hpb=4ad2c87a85ae14ce5681e7ba0bdbe51a2b5175cb;p=developers-reference.git

diff --git a/developers-reference.sgml b/developers-reference.sgml
index ba2a9b7..7adb925 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.152 $">
+  <!entity cvs-rev "$Revision: 1.156 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -2482,11 +2482,16 @@ page for information and procedures.
 It is not OK to simply take over a package that you feel is neglected
 &mdash; that would be package hijacking.  You can, of course, contact the
 current maintainer and ask them if you may take over the package.
-However, without their assent, you may not take over the package.
-Even if they ignore you, that is still not grounds to take over a
-package.  If you really feel that a maintainer has gone AWOL (absent
-without leave), post a query to &email-debian-private;. You may also
-inform the QA group (cf. <ref id="mia-qa">).
+If you have reason to believe a maintainer has gone AWOL
+(absent without leave), see <ref id="mia-qa">.
+	<p>
+Generally, you may not take over the package without the assent of the
+current maintainer. Even if they ignore you, that is still not grounds to
+take over a package. Complaints about maintainers should be brought up on
+the developers' mailing list. If the discussion doesn't end with a positive
+conclusion, and the issue is of a technical nature, consider bringing it to
+the attention of the technical committee (see the <url name="technical
+committee web page" id="&url-tech-ctte;"> for more information).
 	<p>
 If you take over an old package, you probably want to be listed as the
 package's official maintainer in the bug system. This will happen
@@ -3282,9 +3287,9 @@ package(s).  If users want the source of the documentation, they
 should retrieve the source package.</p>
           <p>
 Policy specifies that documentation should be shipped in HTML format.
-We also recommend shipping documentation in PDF and ASCII format if
+We also recommend shipping documentation in PDF and plain text format if
 convenient and quality output is possible.  However, it is generally
-not appropriate to ship ASCII versions of documentation whose source
+not appropriate to ship plain text versions of documentation whose source
 format is HTML.</p>
           <p>
 Major shipped manuals should register themselves with
@@ -3449,21 +3454,6 @@ also respect the maintainer's wishes if he expressed some.
 If someone doesn't feel confident with an NMU, he should just send a patch
 to the BTS. It's far better than a broken NMU.
 
-    <sect id="mia-qa">Dealing with unreachable maintainers
-      <p>
-If you notice that a package is lacking maintenance, you should
-make sure the maintainer is active and will continue to work on
-his packages. Try contacting him yourself.
-      <p>
-If you do not get a reply after a few weeks you should collect all 
-useful information about this maintainer. Start by logging into 
-the <url id="&url-debian-db;" name="Debian Developer's Database">
-and doing a full search to check whether the maintainer is on vacation
-and when they were last seen. Collect any important package names
-they maintain and any Release Critical bugs filed against them.
-      <p>
-Send all this information to &email-debian-qa;, in order to let the 
-QA people do whatever is needed.
 
     <sect id="contacting-maintainers">Contacting other maintainers
       <p>
@@ -3486,6 +3476,75 @@ You can do so by using the <tt>&lt;package-name&gt;@&pts-host;</tt>
 email address.
 
 
+    <sect id="mia-qa">Dealing with inactive and/or unreachable maintainers
+      <p>
+If you notice that a package is lacking maintenance, you should
+make sure that the maintainer is active and will continue to work on
+their packages. It is possible that they are not active any more, but
+haven't registered out of the system, so to speak. On the other hand,
+it is also possible that they just need a reminder.
+      <p>
+The first step is to politely contact the maintainer, and wait for a
+response, for a reasonable time. It is quite hard to define "reasonable
+time", but it is important to take into account that real life is sometimes
+very hectic. One way to handle this would be send a reminder after two
+weeks.
+      <p>
+If the maintainer doesn't reply within four weeks (a month), one can
+assume that a response will probably not happen. If that happens, you
+should investigate further, and try to gather as much useful information
+about the maintainer in question as possible. This includes:
+      <p>
+      <list>
+	<item>The "echelon" information available through the 
+              <url id="&url-debian-db;" name="developers' LDAP database">,
+              which indicates when's the last time a developer has posted to
+              a Debian mailing list. (This includes uploads via
+              debian-*-changes lists.) Also, remember to check whether the
+              maintainer is marked as "on vacation" in the database.
+
+	<item>The number of packages this maintainer is responsible for,
+              and the condition of those packages. In particular, are there
+              any RC bugs that have been open for ages? Furthermore, how
+              many bugs are there in general? Another important piece of
+              information is whether the packages have been NMUed, and if
+              so, by whom?
+
+	<item>Is there any activity of the maintainer outside of Debian? 
+              For example, they might have posted something recently to
+              non-Debian mailing lists or news groups.
+      </list>
+      <p>
+One big problem are packages which were sponsored -- the maintainer is not
+an official Debian developer. The echelon information is not available for
+sponsored people, for example, so you need to find and contact the Debian
+developer who has actually uploaded the package. Given that they signed the
+package, they're responsible for the upload anyhow, and should know what
+happened to the person they sponsored.
+      <p>
+It is also allowed to post a query to &email-debian-devel;, asking if anyone
+is aware of the whereabouts of the missing maintainer.
+      <p>
+Once you have gathered all of this, you can contact &email-debian-qa;.
+People on this alias will use the information you provided in order to
+decide how to proceed. For example, they might orphan one or all of the
+packages of the maintainer. If a packages has been NMUed, they might prefer
+to contact the NMUer before orphaning the package -- perhaps the person who
+has done the NMU is interested in the package.
+      <p>
+One last word: please remember to be polite. We are all volunteers and
+cannot dedicate all of our time to Debian. Also, you are not aware of the
+circumstances of the person who is involved. Perhaps they might be
+seriously ill or might even had died -- you do not know who may be on the
+receiving side -- imagine how a relative will feel if they read the e-mail
+of the deceased and find a very impolite, angry and accusing message!)
+      <p>
+On the other hand, although we are volunteers, we do have a responsibility. 
+So you can stress the importance of the greater good -- if a maintainer does
+not have the time or interest anymore, they should "let go" and give the
+package to someone with more time.
+
+
     <sect id="newmaint">
       <heading>Interacting with prospective Debian developers</heading>
       <p>