chiark / gitweb /
lots of small fixes
authoraba <aba@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 5 Sep 2004 20:33:02 +0000 (20:33 +0000)
committeraba <aba@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 5 Sep 2004 20:33:02 +0000 (20:33 +0000)
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@2567 313b444b-1b9f-4f58-a734-7bb04f332e8d

debian/changelog
developers-reference.sgml

index 61f29a1..151d298 100644 (file)
@@ -3,14 +3,18 @@ developers-reference (3.3.5) unstable; urgency=low
   * Andreas Barth
     - uploads to more than one dist are not possible.
     - updated upload queues. Closes: #235213
-    - updated URL of vanilla rules files. Closes: #237557
+    - updated URL of vanilla rules files. Closes: #237557, #252048
     - please speak with stable RM before uploading to stable. Closes: #261464
     - information on wnpp usage synced with wnpp. Closes: #255298
+    - spelling, grammer fixes.
+      Closes: #202444, #202499, #203202, #203378, #221902, #226208
+    - add hint about partitial key id. Closes: #243968
+    - spohr is restriced, and also ftp-master. Closes: #255814
   * Matt Zimmerman
     - Security uploads get urgency=high
     - Be even more explicit about not uploading security updates
 
- -- Andreas Barth <aba@not.so.argh.org>  Sun,  5 Sep 2004 12:48:32 -0600
+ -- Andreas Barth <aba@not.so.argh.org>  Sun,  5 Sep 2004 14:02:11 -0600
 
 developers-reference (3.3.4) unstable; urgency=low
 
index b3d286b..5c10c64 100644 (file)
@@ -2,11 +2,11 @@
   <!-- include version information so we don't have to hard code it
        within the document -->
   <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
-  <!-- common, language independant entities -->
+  <!-- common, language independent entities -->
   <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.229 $">
+  <!ENTITY cvs-rev "$Revision: 1.230 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -77,7 +77,7 @@ resources which can help maintainers with the quality of their
 packages (<ref id="tools">).
       <p>
 It should be clear that this reference does not discuss the technical
-details of the Debian package nor how to generate Debian packages.
+details of Debian packages nor how to generate them.
 Nor does this reference detail the standards to which Debian software
 must comply.  All of such information can be found in the <url
 id="&url-debian-policy;" name="Debian Policy Manual">.
@@ -332,7 +332,7 @@ security update, etc.) occurs while you're on vacation. Sometimes it's
 nothing as critical as that, but it's still appropriate to let the others
 know that you're unavailable.
        <p>
-In order to inform the other developers, there's two things that you should do.
+In order to inform the other developers, there are two things that you should do.
 First send a mail to &email-debian-private; with "[VAC] " prepended to the
 subject of your message<footnote>This is so that the message can be easily
 filtered by people who don't want to read vacation notices.</footnote>
@@ -356,7 +356,7 @@ they can be fixed in a future upstream release.
 While it's not your job to fix non-Debian specific bugs, you may freely
 do so if you're able. When you make such fixes, be sure to pass them on
 to the upstream maintainers as well. Debian users and developers will
-sometimes submit patches to fix upstream bugs -- you should evaluate
+sometimes submit patches to fix upstream bugs &mdash; you should evaluate
 and forward these patches upstream.
         <p>
 If you need to modify the upstream sources in order to build a policy
@@ -370,7 +370,7 @@ need, always try not to fork from the upstream sources.
         <p>
 Generally you should deal with bug reports on your packages as described in
 <ref id="bug-handling">. However, there's a special category of bugs that
-you need to take care of -- the so-called release-critical bugs (RC bugs).
+you need to take care of &mdash; the so-called release-critical bugs (RC bugs).
 All bug reports that have severity <em>critical</em>, <em>grave</em> or
 <em>serious</em> are considered to have an impact on whether the package can
 be released in the next stable release of Debian.
@@ -589,17 +589,22 @@ administration (such as packages to be removed from the archive,
 suggestions for the web site, etc.),
 generally you'll report a bug against a ``pseudo-package''.  See <ref
 id="submit-bug"> for information on how to submit bugs.
+       <p>
+Some of the core servers are restricted, but the information from there
+is mirror to another server.
 
       <sect1 id="servers-bugs">The bugs server
        <p>
 <tt>&bugs-host;</tt> is the canonical location for the Bug Tracking
-System (BTS).  If you plan on doing some statistical analysis or
+System (BTS).
+       <p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+       <p>
+If you plan on doing some statistical analysis or
 processing of Debian bugs, this would be the place to do it.  Please
 describe your plans on &email-debian-devel; before implementing
 anything, however, to reduce unnecessary duplication of effort or
 wasted processing time.
-       <p>
-All Debian developers have accounts on <tt>&bugs-host;</tt>.
 
       <sect1 id="servers-ftp-master">The ftp-master server
        <p>
@@ -607,6 +612,8 @@ The <tt>ftp-master.debian.org</tt> server holds the canonical copy of the Debian
 archive (excluding the non-US packages). Generally, package uploads
 go to this server; see <ref id="upload">.
        <p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+       <p>
 Problems with the Debian FTP archive generally need to be reported as
 bugs against the <package>ftp.debian.org</package> pseudo-package or
 an email to &email-ftpmaster;, but also see the procedures in
@@ -886,7 +893,8 @@ distribution changes from day-to-day. Since no special effort is done
 to make sure everything in this distribution is working properly, it is
 sometimes literally unstable.
        <p>
-<qref id="testing">"testing"</qref> is generated automatically by taking
+The <qref id="testing">"testing"</qref> distribution is generated
+automatically by taking
 packages from unstable if they satisfy certain criteria. Those
 criteria should ensure a good quality for packages within testing.
 The update to testing is launched each day after the
@@ -1140,7 +1148,11 @@ or to move some files back in the <file>unchecked</file> directory. But
 all the other directories are only writable by the ftpmasters, that is
 why you can not remove an upload once it has been accepted.
 
-      <sect1 id="delayed-incoming">Delayed incoming
+      <sect1 id="delayed-incoming-broken">Delayed incoming
+       <p>
+<em>Note:</em> This description here is currently disabled, because
+ftp-master is restricted. Please see <ref id="delayed-incoming"> for
+the currently working way.
        <p>
 The <file>unchecked</file> directory has a special <file>DELAYED</file>
 subdirectory. It is itself subdivided in nine directories
@@ -1818,7 +1830,7 @@ advice. Again, it is strongly recommended that U.S. citizens and
 residents consult a lawyer before doing uploads to non-US.
 
 
-       <sect1>Delayed uploads
+       <sect1 id="delayed-incoming">Delayed uploads
          <p>
 Delayed uploads are done for the moment via the delayed queue at
 gluck. The upload-directory is
@@ -3189,7 +3201,7 @@ available at <url id="&url-rules-files;">.
           <heading>Separating your patches into multiple files</heading>
           <p>
 Big, complex packages may have many bugs that you need to deal with.
-If you correct a number of bug directly in the source, if you're not
+If you correct a number of bugs directly in the source, and you're not
 careful, it can get hard to differentiate the various patches that you
 applied.  It can get quite messy when you have to update the package
 to a new upstream version which integrates some of the fixes (but not
@@ -3984,7 +3996,7 @@ about the maintainer in question as possible. This includes:
               non-Debian mailing lists or news groups.
       </list>
       <p>
-One big problem are packages which were sponsored -- the maintainer is not
+One big problem are packages which were sponsored &mdash; 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
@@ -3998,18 +4010,18 @@ 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
+to contact the NMUer before orphaning the package &mdash; 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
+seriously ill or might even had died &mdash; you do not know who may be on the
+receiving side &mdash; 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
+So you can stress the importance of the greater good &mdash; if a maintainer does
 not have the time or interest anymore, they should "let go" and give the
 package to someone with more time.
 
@@ -4070,7 +4082,9 @@ means being a mentor.
        <p>
 Once the package meets Debian standards, build and sign it with                           
 <example>dpkg-buildpackage -k<var>KEY-ID</var></example>                                  
-before uploading it to the incoming directory.
+before uploading it to the incoming directory. Of course, you can also
+use any part of your <var>KEY-ID</var>, as long as it's uniq in your
+secret keyring.
        <p>
 The Maintainer field of the <file>control</file> file and the
 <file>changelog</file> should list the person who did the packaging, i.e., the