From 8e5bea309b68373c2d1e2038f22cd2ce241018c0 Mon Sep 17 00:00:00 2001 From: hertzog Date: Mon, 25 Jun 2012 19:00:50 +0000 Subject: [PATCH] Reword various parts to be gender-neutral Thanks to Per Andersson and Steve Langasek for the patch. Closes: #678712 git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@9233 313b444b-1b9f-4f58-a734-7bb04f332e8d --- best-pkging-practices.dbk | 10 +++++----- beyond-pkging.dbk | 34 +++++++++++++++++----------------- debian/changelog | 2 ++ developer-duties.dbk | 4 ++-- l10n.dbk | 2 +- pkgs.dbk | 16 ++++++++-------- resources.dbk | 2 +- 7 files changed, 36 insertions(+), 34 deletions(-) diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk index 575a80f..2316f19 100644 --- a/best-pkging-practices.dbk +++ b/best-pkging-practices.dbk @@ -1630,9 +1630,9 @@ incrementing the version number, so there can be no guarantee that a pristine tarball is identical to what upstream currently distributing at any point in time. All that can be expected is that it is identical to something that upstream once did distribute. -If a difference arises later (say, if upstream notices that he wasn't using -maximal compression in his original distribution and then -re-gzips 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-gzip it), that's just too bad. Since there is no good way to upload a new .orig.tar.{gz,bz2,xz} for the same version, there is not even any point in treating this situation as a bug. This makes it possible to use checksums to easily verify that all changes between Debian's @@ -1688,7 +1688,7 @@ that you must remove before uploading. In these cases the developer must construct a suitable .orig.tar.{gz,bz2,xz} -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 .diff.gz or .debian.tar.{gz,bz2,xz} @@ -1856,7 +1856,7 @@ of meta-packages (built by the source packages 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 --git a/beyond-pkging.dbk b/beyond-pkging.dbk index 88056fc..371fba2 100644 --- a/beyond-pkging.dbk +++ b/beyond-pkging.dbk @@ -346,13 +346,13 @@ the package is maintained. The sponsor downloads (or checkouts) the source package. -The sponsor reviews the source package. If she finds issues, she -informs the maintainer and asks her to provide a fixed version (the +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). -The sponsor could not find any remaining problem. She builds the -package, signs it, and uploads it to Debian. +The sponsor could not find any remaining problem. They build the +package, sign it, and upload it to Debian. @@ -369,15 +369,15 @@ and how large is the user base? How active are the upstream developers? 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? -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 @@ remove and purge the packages. Maybe test them with piuparts. 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 . @@ -482,7 +482,7 @@ Note that you should not need to modify the source package to put your name in the changelog or in the control file. The Maintainer field of the control file and the changelog 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. Instead you should instruct dpkg-buildpackage to use your key for the signature. You do that with the -k option: @@ -539,11 +539,11 @@ linkend="pkg-tracking-system"/>) to verify if the 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 testing. 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 testing. +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. If you have found no major problem, upload the new version. Otherwise diff --git a/debian/changelog b/debian/changelog index d2468b2..b50e5a6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,8 @@ developers-reference (3.4.9) UNRELEASED; urgency=low * Clarify that removals from testing are possible. Closes: #678710 Thanks to Per Andersson for the patch. + * Reword various parts to be gender-neutral. Closes: #678712 + Thanks to Per Andersson and Steve Langasek for the patch. -- Raphaël Hertzog Mon, 25 Jun 2012 20:46:20 +0200 diff --git a/developer-duties.dbk b/developer-duties.dbk index 6b60b65..0ca0ee5 100644 --- a/developer-duties.dbk +++ b/developer-duties.dbk @@ -37,7 +37,7 @@ given transition if you are not able to identify them. Maintain packages in <literal>stable</literal> Most of the package maintainer's work goes into providing updated -versions of packages in unstable, but his job also entails taking care +versions of packages in unstable, but their job also entails taking care of the packages in the current stable release. @@ -77,7 +77,7 @@ can block the testing migration of many packages. 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 ). diff --git a/l10n.dbk b/l10n.dbk index a089e64..531a600 100644 --- a/l10n.dbk +++ b/l10n.dbk @@ -158,7 +158,7 @@ speakers. How to handle a bug report concerning a translation 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). diff --git a/pkgs.dbk b/pkgs.dbk index 9c03fa7..3ce0bee 100644 --- a/pkgs.dbk +++ b/pkgs.dbk @@ -1958,11 +1958,11 @@ maintainer by other means (private email, IRC). 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. @@ -2124,7 +2124,7 @@ allows the developer doing the NMU to perform all the necessary tasks at the 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 -DELAYED/7 and tell the maintainer that he has 7 days to +DELAYED/7 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. @@ -2133,12 +2133,12 @@ more, or cancel your upload. The DELAYED 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. If you make an NMU to DELAYED 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. diff --git a/resources.dbk b/resources.dbk index 61d8748..4421a32 100644 --- a/resources.dbk +++ b/resources.dbk @@ -627,7 +627,7 @@ development process of the Debian project. Active development is done in the unstable distribution (that's why this distribution is sometimes called the development -distribution). Every Debian developer can update his or her +distribution). 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 -- 2.30.2