Bug#685339: unblock: developers-reference/3.4.9
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock
Please unblock package developers-reference
It's just a documentation and translation update. Please find attached
the debdiff dropping the translations (--exclude *.po --exclude *.pot).
unblock developers-reference/3.4.9
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diffstat for developers-reference-3.4.8 developers-reference-3.4.9
README-contrib | 10 +++++++++
best-pkging-practices.dbk | 10 ++++-----
beyond-pkging.dbk | 34 ++++++++++++++++-----------------
common.ent | 1
debian/changelog | 25 ++++++++++++++++++++++++
debian/control | 2 -
developer-duties.dbk | 4 +--
l10n.dbk | 2 -
pkgs.dbk | 47 ++++++++++++++++++++++++++++------------------
resources.dbk | 4 +--
10 files changed, 93 insertions(+), 46 deletions(-)
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/best-pkging-practices.dbk developers-reference-3.4.9/best-pkging-practices.dbk
--- developers-reference-3.4.8/best-pkging-practices.dbk 2012-06-25 10:47:03.000000000 -0400
+++ developers-reference-3.4.9/best-pkging-practices.dbk 2012-06-25 15:00:50.000000000 -0400
@@ -1630,9 +1630,9 @@
tarball is identical to what upstream <emphasis>currently</emphasis>
distributing at any point in time. All that can be expected is that it is
identical to something that upstream once <emphasis>did</emphasis> distribute.
-If a difference arises later (say, if upstream notices that he wasn't using
-maximal compression in his original distribution and then
-re-<command>gzip</command>s it), that's just too bad. Since there is no good
+If a difference arises later (say, if upstream notice that they weren't using
+maximal compression in their original distribution and then
+re-<command>gzip</command> it), that's just too bad. Since there is no good
way to upload a new <filename>.orig.tar.{gz,bz2,xz}</filename> for the same version, there is not even any
point in treating this situation as a bug. </para> </footnote> This makes it
possible to use checksums to easily verify that all changes between Debian's
@@ -1688,7 +1688,7 @@
</para>
<para>
In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,xz}</filename>
-file himself. We refer to such a tarball as a repackaged upstream
+file themselves. We refer to such a tarball as a repackaged upstream
source. Note that a repackaged upstream source is different from a
Debian-native package. A repackaged source still comes with Debian-specific
changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,xz}</filename>
@@ -1856,7 +1856,7 @@
</para>
<para>
The long description of the meta-package must clearly document its purpose
-so that the user knows what he will lose if he removes the package. Being
+so that the user knows what they will lose if they remove the package. Being
explicit about the consequences is recommended. This is particularly
important for meta-packages which are installed during initial
installation and that have not been explicitly installed by the user.
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/beyond-pkging.dbk developers-reference-3.4.9/beyond-pkging.dbk
--- developers-reference-3.4.8/beyond-pkging.dbk 2011-07-05 02:04:26.000000000 -0400
+++ developers-reference-3.4.9/beyond-pkging.dbk 2012-06-25 15:00:50.000000000 -0400
@@ -346,13 +346,13 @@
<para>The sponsor downloads (or checkouts) the source package.</para>
</listitem>
<listitem>
-<para>The sponsor reviews the source package. If she finds issues, she
-informs the maintainer and asks her to provide a fixed version (the
+<para>The sponsor reviews the source package. If they find issues, they
+inform the maintainer and ask them to provide a fixed version (the
process starts over at step 1).</para>
</listitem>
<listitem>
-<para>The sponsor could not find any remaining problem. She builds the
-package, signs it, and uploads it to Debian.</para>
+<para>The sponsor could not find any remaining problem. They build the
+package, sign it, and upload it to Debian.</para>
</listitem>
</orderedlist>
</para>
@@ -369,15 +369,15 @@
</para>
<para>
You should also ensure that the prospective maintainer is going
-to be a good maintainer. Does she already have some experience with other
-packages? If yes, is she doing a good job with them (check out some bugs)?
-Is she familiar with the package and its programming language?
-Does she have the skills needed for this package? If not, is she able
+to be a good maintainer. Do they already have some experience with other
+packages? If yes, are they doing a good job with them (check out some bugs)?
+Are they familiar with the package and its programming language?
+Do they have the skills needed for this package? If not, are they able
to learn them?
</para>
<para>
-It's also a good idea to know where she stands towards Debian: does
-she agree with Debian's philosophy and does she intend to join Debian?
+It's also a good idea to know where they stand with respect to Debian: do
+they agree with Debian's philosophy and do they intend to join Debian?
Given how easy it is to become a Debian Maintainer, you might want
to only sponsor people who plan to join. That way you know from the start
that you won't have to act as a sponsor indefinitely.
@@ -473,7 +473,7 @@
<para>
If the audit did not reveal any problem, you can build the package and
upload it to Debian. Remember that even if you're not the maintainer,
-the sponsor is still responsible of what he uploaded to Debian. That's
+as a sponsor you are still responsible for what you upload to Debian. That's
why you're encouraged to keep up with the package through the
<xref linkend="pkg-tracking-system"/>.
</para>
@@ -482,7 +482,7 @@
in the <filename>changelog</filename> or in the <filename>control</filename> file. The <literal>Maintainer</literal>
field of the <filename>control</filename> file and the
<filename>changelog</filename> should list the person who did the
-packaging, i.e. the sponsoree. That way she will get all the BTS mail.
+packaging, i.e. the sponsoree. That way they will get all the BTS mail.
</para>
<para>Instead you should instruct <command>dpkg-buildpackage</command> to use your key for
the signature. You do that with the <literal>-k</literal> option:</para>
@@ -539,11 +539,11 @@
maintainer has not missed something important. Maybe there are translations
updates sitting in the BTS that could have been integrated. Maybe the package
has been NMUed and the maintainer forgot to integrate the changes from the
-NMU in his package. Maybe there's a release critical bug that he has left
-unhandled and that's blocking migration to <literal>testing</literal>. Whatever. If you find
-something that she could have done (better), it's time to tell her so that
-she can improve for next time, and so that she has a better understanding
-of her responsibilities.
+NMU into their package. Maybe there's a release critical bug that they have
+left unhandled and that's blocking migration to <literal>testing</literal>.
+If you find something that they could have done (better), it's time to tell
+them so that they can improve for next time, and so that they have a better
+understanding of their responsibilities.
</para>
<para>
If you have found no major problem, upload the new version. Otherwise
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/common.ent developers-reference-3.4.9/common.ent
--- developers-reference-3.4.8/common.ent 2012-06-25 10:47:04.000000000 -0400
+++ developers-reference-3.4.9/common.ent 2012-06-25 15:00:48.000000000 -0400
@@ -27,6 +27,7 @@
<!ENTITY master-host "master.debian.org">
<!ENTITY www-debian-org "www.debian.org">
<!ENTITY ftp-debian-org "ftp.debian.org">
+<!ENTITY release-debian-org "release.debian.org">
<!ENTITY lists-host "lists.debian.org">
<!ENTITY archive-host "archive.debian.org">
<!ENTITY keyserver-host "keyring.debian.org">
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/debian/changelog developers-reference-3.4.9/debian/changelog
--- developers-reference-3.4.8/debian/changelog 2012-06-25 14:41:28.000000000 -0400
+++ developers-reference-3.4.9/debian/changelog 2012-08-19 17:35:39.000000000 -0400
@@ -1,3 +1,28 @@
+developers-reference (3.4.9) unstable; urgency=low
+
+ * Team upload.
+
+ [ Raphaël Hertzog ]
+ * Clarify that removals from testing are possible. Closes: #678710
+ Thanks to Per Andersson <avtobiff@gmail.com> for the patch.
+ * Reword various parts to be gender-neutral. Closes: #678712
+ Thanks to Per Andersson and Steve Langasek for the patch.
+ * Recommend usage of gender-neutral formulations in README-contrib.
+ * Fix Vcs-Browser URL. Thanks to Charles Plessy who spotted it.
+ * Document the existence of "hints" that release managers can
+ use to tweak the conditions of testing migration. Closes: #679562
+ Thanks to Paul Gevers <paul@climbing.nl> for the patch.
+
+ [ Translation updates ]
+ * Japanese by Hideki Yamane.
+ * French by David Prévot.
+ * German by Chris Leick.
+
+ [ David Prévot ]
+ * Fix typo: Freenodes -> Freenode. Closes: #679735
+
+ -- David Prévot <taffit@debian.org> Sun, 19 Aug 2012 17:34:59 -0400
+
developers-reference (3.4.8) unstable; urgency=low
[ David Prévot ]
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/debian/control developers-reference-3.4.9/debian/control
--- developers-reference-3.4.8/debian/control 2012-06-25 14:40:48.000000000 -0400
+++ developers-reference-3.4.9/debian/control 2012-06-26 05:19:45.000000000 -0400
@@ -9,7 +9,7 @@
texlive-lang-cyrillic, texlive-lang-french, texlive-lang-german, texlive-xetex
Build-Depends: debhelper (>= 8), dpkg-dev (>= 1.16.1~)
Vcs-Svn: svn://svn.debian.org/ddp/manuals/trunk/developers-reference
-Vcs-Browser: http://svn.debian.org/wsvn/ddp/manuals/trunk/developers-reference?op=log
+Vcs-Browser: http://anonscm.debian.org/viewvc/ddp/manuals/trunk/developers-reference/
Package: developers-reference
Architecture: all
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/developer-duties.dbk developers-reference-3.4.9/developer-duties.dbk
--- developers-reference-3.4.8/developer-duties.dbk 2012-06-25 10:47:03.000000000 -0400
+++ developers-reference-3.4.9/developer-duties.dbk 2012-06-25 15:00:50.000000000 -0400
@@ -37,7 +37,7 @@
<title>Maintain packages in <literal>stable</literal></title>
<para>
Most of the package maintainer's work goes into providing updated
-versions of packages in <literal>unstable</literal>, but his job also entails taking care
+versions of packages in <literal>unstable</literal>, but their job also entails taking care
of the packages in the current <literal>stable</literal> release.
</para>
<para>
@@ -77,7 +77,7 @@
</para>
<para>
Lack of attention to RC bugs is often interpreted by the QA team as a sign
-that the maintainer has disappeared without properly orphaning his package.
+that the maintainer has disappeared without properly orphaning their package.
The MIA team might also get involved, which could result in your packages
being orphaned (see <xref linkend="mia-qa" />).
</para>
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/l10n.dbk developers-reference-3.4.9/l10n.dbk
--- developers-reference-3.4.8/l10n.dbk 2010-11-24 18:33:55.000000000 -0400
+++ developers-reference-3.4.9/l10n.dbk 2012-06-25 15:00:50.000000000 -0400
@@ -158,7 +158,7 @@
<title>How to handle a bug report concerning a translation</title>
<para>
The best solution may be to mark the bug as forwarded to upstream, and forward
-it to both the previous translator and his/her team (using the corresponding
+it to both the previous translator and their team (using the corresponding
debian-l10n-XXX mailing list).
<!-- TODO: add the i18n tag to the bug? -->
</para>
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/pkgs.dbk developers-reference-3.4.9/pkgs.dbk
--- developers-reference-3.4.8/pkgs.dbk 2012-06-25 10:47:03.000000000 -0400
+++ developers-reference-3.4.9/pkgs.dbk 2012-08-08 21:48:39.000000000 -0400
@@ -1309,7 +1309,10 @@
<literal>testing</literal> directly. Rather, they will be removed
automatically after the package has been removed from
<literal>unstable</literal> and no package in
-<literal>testing</literal> depends on it.
+<literal>testing</literal> depends on it. (Removals from
+<literal>testing</literal> are possible though by filing a removal bug report
+against the <systemitem role="package">&release-debian-org;</systemitem>
+pseudo-package. See the section <xref linkend="removals"/>.)
</para>
<para>
There is one exception when an explicit removal request is not necessary: If a
@@ -1955,11 +1958,11 @@
<listitem>
<para>
If the maintainer is usually active and responsive, have you tried to contact
-him? In general it should be considered preferable that a maintainer takes care
-of an issue himself and that he is given the chance to review and correct your
-patch, because he can be expected to be more aware of potential issues which an
-NMUer might miss. It is often a better use of everyone's time if the maintainer
-is given an opportunity to upload a fix on their own.
+them? In general it should be considered preferable that maintainers take care
+of an issue themselves and that they are given the chance to review and
+correct your patch, because they can be expected to be more aware of potential
+issues which an NMUer might miss. It is often a better use of everyone's time
+if the maintainer is given an opportunity to upload a fix on their own.
</para>
</listitem>
</itemizedlist>
@@ -2121,7 +2124,7 @@
same time. For instance, instead of telling the maintainer that you will
upload the updated
package in 7 days, you should upload the package to
-<literal>DELAYED/7</literal> and tell the maintainer that he has 7 days to
+<literal>DELAYED/7</literal> and tell the maintainer that they have 7 days to
react. During this time, the maintainer can ask you to delay the upload some
more, or cancel your upload.
</para>
@@ -2130,12 +2133,12 @@
The <literal>DELAYED</literal> queue should not be used to put additional
pressure on the maintainer. In particular, it's important that you are
available to cancel or delay the upload before the delay expires since the
-maintainer cannot cancel the upload himself.
+maintainer cannot cancel the upload themselves.
</para>
<para>
If you make an NMU to <literal>DELAYED</literal> and the maintainer updates
-his package before the delay expires, your upload will be rejected because a
+the package before the delay expires, your upload will be rejected because a
newer version is already available in the archive.
Ideally, the maintainer will take care to include your proposed changes (or
at least a solution for the problems they address) in that upload.
@@ -2383,9 +2386,7 @@
The package must have been available in <literal>unstable</literal> for 2, 5
or 10 days, depending on the urgency (high, medium or low). Please note that
the urgency is sticky, meaning that the highest urgency uploaded since the
-previous <literal>testing</literal> transition is taken into account. Those
-delays may be doubled during a freeze, or <literal>testing</literal>
-transitions may be switched off altogether;
+previous <literal>testing</literal> transition is taken into account;
</para>
</listitem>
<listitem>
@@ -2413,7 +2414,13 @@
The packages on which it depends must either be available in
<literal>testing</literal> or they must be accepted into
<literal>testing</literal> at the same time (and they will be if they fulfill
-all the necessary criteria).
+all the necessary criteria);
+</para>
+</listitem>
+<listitem>
+<para>
+The phase of the project. I.e. automatic transitions are turned off during
+the <emphasis>freeze</emphasis> of the <literal>testing</literal> distribution.
</para>
</listitem>
</itemizedlist>
@@ -2625,10 +2632,8 @@
The packages are looked at to determine whether they are valid candidates.
This gives the update excuses. The most common reasons why a package is not
considered are too young, RC-bugginess, and out of date on some arches. For
-this part of britney, the release managers have hammers of various sizes to
-force britney to consider a package. (Also, the base freeze is coded in that
-part of britney.) (There is a similar thing for binary-only updates, but this
-is not described here. If you're interested in that, please peruse the code.)
+this part of britney, the release managers have hammers of various sizes,
+called hints (see below), to force britney to consider a package.
</para>
<para>
Now, the more complex part happens: Britney tries to update <literal>testing</literal>
@@ -2646,7 +2651,13 @@
</para>
<para>
The hints are available via <ulink
-url="http://&ftp-master-host;/testing/hints/";></ulink>.
+url="http://&ftp-master-host;/testing/hints/";></ulink>, where you can find
+the
+<ulink url="http://&ftp-master-host;/testing/hints/README";>description</ulink>
+as well. With the hints, the Debian Release team can block or unblock
+packages, ease or force packages into <literal>testing</literal>, remove
+packages from <literal>testing</literal>, approve uploads to
+<link linkend="t-p-u">testing-proposed-updates</link> or override the urgency.
</para>
</section>
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/README-contrib developers-reference-3.4.9/README-contrib
--- developers-reference-3.4.8/README-contrib 2012-06-25 10:47:03.000000000 -0400
+++ developers-reference-3.4.9/README-contrib 2012-06-26 02:46:11.000000000 -0400
@@ -47,6 +47,16 @@
SVN access for other reasons.
+* Writing style
+
+Please use gender-neutral formulations. This means avoiding
+pronouns like he/she when referring to a role (like "maintainer")
+whose gender is unknown. Instead of you should use the
+plural form (singular they [1]).
+
+[1] http://en.wikipedia.org/wiki/Singular_they
+
+
* SVN
If you're interested in ongoing maintenance, once you've shown that
diff -Nru --exclude '*.po' --exclude '*.pot' developers-reference-3.4.8/resources.dbk developers-reference-3.4.9/resources.dbk
--- developers-reference-3.4.8/resources.dbk 2012-06-25 10:47:04.000000000 -0400
+++ developers-reference-3.4.9/resources.dbk 2012-07-28 16:58:55.000000000 -0400
@@ -184,7 +184,7 @@
Subject: header. The nick should be registered: <ulink
url="http://freenode.net/faq.shtml#nicksetup";>Nick Setup Page</ulink>. The
mail needs to be signed by a key in the Debian keyring. Please see <ulink
-url="http://freenode.net/faq.shtml#projectcloak";>Freenodes
+url="http://freenode.net/faq.shtml#projectcloak";>Freenode
documentation</ulink> for more information about cloaks.
</para>
</section>
@@ -627,7 +627,7 @@
<para>
Active development is done in the <literal>unstable</literal> distribution
(that's why this distribution is sometimes called the <literal>development
-distribution</literal>). Every Debian developer can update his or her
+distribution</literal>). Every Debian developer can update their
packages in this distribution at any time. Thus, the contents of this
distribution change from day to day. Since no special effort is made to make
sure everything in this distribution is working properly, it is sometimes
Reply to: