<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.247 $">
+ <!ENTITY cvs-rev "$Revision: 1.252 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
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>
<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
most concise entry and the easiest to integrate with the text of the
<file>changelog</file>.
<p>
+If an upload is identified as <ref id="nmu" name="Non-maintainer upload (NMU)">
+(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
This section handles only source NMUs, i.e. NMUs which upload a new
version of the package. For binary-only NMUs by porters or QA members,
please see <ref id="binary-only-nmu">.
-For buildd uploads (which are strictly speaking also NMUs), please see <ref
-id="buildd">.
+If a buildd builds and uploads a package,
+that too is strictly speaking a binary NMU.
+See <ref id="buildd"> for some more information.
<p>
The main reason why NMUs are done is when a
developer needs to fix another developer's packages in order to
Keep in mind that packages uploaded there are not automatically processed, they
have to go through the hands of the release manager. So you'd better have a good
reason to upload there. In order to know what a good reason is in the
-release manager's eyes, you should read the instructions that he regularly
-gives on &email-debian-devel-announce;.
-<!-- FIXME: gender-specific; fix when RM is female at the very latest -->
+release managers' eyes, you should read the instructions that they regularly
+give on &email-debian-devel-announce;.
<p>
You should not upload to <em>testing-proposed-updates</em> when you can update your
packages through <em>unstable</em>. If you can't (for example because you have a
<p>
Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
<p>
-The "testing" bug count for a package is considered to be roughly the bug count at the last point when the "testing" version equalled the "unstable" version. The bugs tagged woody or sarge will not be counted. Bugs with the sid tag will be counted, though.
+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 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.
<sect2>
<item>
How is this package different from the competition? Is it a better
implementation? more features? different features? Why should I
-choose this package (the second questions is about the class of packages, and
+choose this package.
+<!-- FIXME: what's this?
+(the second questions is about the class of packages, and
this about this particular package, if you have information related to both).
+-->
</list>
</sect1>
~ianmdlvl / developers-reference.git / blobdiff