Sync to CVS 1.254

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

diff --git a/developers-reference.sgml b/developers-reference.sgml
index f49fbe836bbfcb9c2a059db464d2e631743f5187..80bd2ae62f40b572a9acb90ab1c0ae681a942d61 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -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.249 $">
+  <!ENTITY cvs-rev "$Revision: 1.254 $">

 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->


@@ -692,7 +692,7 @@ aforementioned <tt>non-us.debian.org</tt>.
 Send mail to &email-debian-devel; if you have any questions.
 
       <sect1 id="servers-cvs">The CVS server
 Send mail to &email-debian-devel; if you have any questions.
 
       <sect1 id="servers-cvs">The CVS server

-<!-- TODO: document svn.debian.org also -->
+<!-- TODO: document svn.debian.org, arch.debian.org also -->

        <p>
 Our CVS server is located on <tt>cvs.debian.org</tt>.
        <p>
        <p>
 Our CVS server is located on <tt>cvs.debian.org</tt>.
        <p>


@@ -1206,7 +1206,8 @@ You can view the bugs of a given package at the URL
       <sect1 id="madison">The <prgn>madison</prgn> utility
         <p>
 <prgn>madison</prgn> is a command-line utility that is available
       <sect1 id="madison">The <prgn>madison</prgn> utility
         <p>
 <prgn>madison</prgn> is a command-line utility that is available

-on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>. It
+on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>, and on
+the mirror on <tt>&ftp-master-mirror;</tt>. It

 uses a single argument corresponding to a package name. In result
 it displays which version of the package is available for each
 architecture and distribution combination. An example will explain
 uses a single argument corresponding to a package name. In result
 it displays which version of the package is available for each
 architecture and distribution combination. An example will explain


@@ -2100,6 +2101,17 @@ We prefer the <tt>closes: #<var>XXX</var></tt> syntax, as it is the
 most concise entry and the easiest to integrate with the text of the
 <file>changelog</file>.
        <p>
 most concise entry and the easiest to integrate with the text of the
 <file>changelog</file>.
        <p>

+If an upload is identified as <qref id="nmu">Non-maintainer upload (NMU)</qref>
+(and that is the case if the name of the person who commits this change
+is not exactly the same as any one of Maintainer or Uploader,
+except if the maintainer is the qa group),
+than the bug is only tagged <tt>fixed</tt> instead of being closed.
+If a maintainer upload is targetted to experimental,
+than the tag <tt>fixed-in-experimental</tt> is added to the bug;
+for NMUs, the tag <tt>fixed</tt> is used.
+(The special rule for experimental is expected to change
+as soon as version-tracking is added to the bug tracking system.)
+       <p>

 If you happen to mistype a bug number or forget a bug in the changelog
 entries, don't hesitate to undo any damage the error caused. To reopen
 wrongly closed bugs, send an <tt>reopen <var>XXX</var></tt> command to
 If you happen to mistype a bug number or forget a bug in the changelog
 entries, don't hesitate to undo any damage the error caused. To reopen
 wrongly closed bugs, send an <tt>reopen <var>XXX</var></tt> command to


@@ -3399,7 +3411,9 @@ Such bugs are presumed to have an impact on the chances that the package will be
 The unstable bug count are all release-critical bugs
 without either any release-tag (such as potato, woody) or with release-tag sid;
 also, only if they are neither fixed nor set to sarge-ignore.
 The unstable bug count are all release-critical bugs
 without either any release-tag (such as potato, woody) or with release-tag sid;
 also, only if they are neither fixed nor set to sarge-ignore.

-The "testing" bug count for a package is considered to be roughly the bug of unstable count at the last point when the "testing" version equalled the "unstable" version.
+The "testing" bug count for a package is considered to be roughly
+the bug count of unstable count at the last point
+when the "testing" version equalled the "unstable" version.

        <p>
 This will change post-sarge, as soon as we have versions in the bug tracking system.
 
        <p>
 This will change post-sarge, as soon as we have versions in the bug tracking system.
 


@@ -4788,9 +4802,11 @@ Sponsoring a package means uploading a package for a maintainer who is not
 able to do it on their own, a new maintainer applicant. Sponsoring a package
 also means accepting responsibility for it.
        <p>
 able to do it on their own, a new maintainer applicant. Sponsoring a package
 also means accepting responsibility for it.
        <p>

+       <!-- FIXME: service down

 If you wish to volunteer as a sponsor, you can sign up at <url
 id="&url-sponsors;">.
        <p>
 If you wish to volunteer as a sponsor, you can sign up at <url
 id="&url-sponsors;">.
        <p>

+       -->

 New maintainers usually have certain difficulties creating Debian packages
 &mdash; this is quite understandable. That is why the sponsor is there, to check
 the package and verify that it is good enough for inclusion in Debian.
 New maintainers usually have certain difficulties creating Debian packages
 &mdash; this is quite understandable. That is why the sponsor is there, to check
 the package and verify that it is good enough for inclusion in Debian.