chiark / gitweb /
replaced the mia-qa section with what Martin Michlmayr wrote, plus proofreading by...
authorjoy <joy@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sat, 21 Dec 2002 18:53:34 +0000 (18:53 +0000)
committerjoy <joy@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sat, 21 Dec 2002 18:53:34 +0000 (18:53 +0000)
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@2013 313b444b-1b9f-4f58-a734-7bb04f332e8d

developers-reference.sgml

index 84e5ca4240d164407a7ea0c82b37056001a5c1d1..173075a020000fa3465c374dd878d69b3168c5b1 100644 (file)
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.154 $">
+  <!entity cvs-rev "$Revision: 1.155 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -3471,21 +3471,70 @@ You can do so by using the <tt>&lt;package-name&gt;@&pts-host;</tt>
 email address.
 
 
 email address.
 
 
-    <sect id="mia-qa">Dealing with unreachable maintainers
+    <sect id="mia-qa">Dealing with inactive and/or unreachable maintainers
       <p>
 If you notice that a package is lacking maintenance, you should
       <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.
+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>
       <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.
+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>
       <p>
-Send all this information to &email-debian-qa;, in order to let the 
-QA people do whatever is needed.
+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>
+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">
 
 
     <sect id="newmaint">