From 47bd8a4fd3caeb43ac150b10ed0ed4b8fca7ec3c Mon Sep 17 00:00:00 2001 From: aba Date: Sat, 11 Nov 2006 20:56:21 +0000 Subject: [PATCH] more language git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@3949 313b444b-1b9f-4f58-a734-7bb04f332e8d --- debian/changelog | 7 +- developers-reference.sgml | 168 +++++++++++++++++++------------------- 2 files changed, 90 insertions(+), 85 deletions(-) diff --git a/debian/changelog b/debian/changelog index 7aa606c..db1977d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -10,7 +10,7 @@ developers-reference (3.3.8) unstable; urgency=low * irc.d.o points to oftc. Thanks, Christoph Biedl, Jon Dowland. Closes: #382721 * Bugs are now always closed thanks to version tracking. - Closes: #339552, #353447 + Closes: #339552, #353447, #376199 * Clarify what "a conflicts b" means in testing migration. Closes: #361311 * Packages in testing disappear if they're removed from unstable. @@ -19,8 +19,9 @@ developers-reference (3.3.8) unstable; urgency=low to Kevin Glynn to the suggestion. Closes: #374738 * Add more tools for reverse depends. Close: #376582 * delayed-queue on gluck is uploaded more often now. Closes: #397907 - * stop using capitals, minor fixes. Thanks, Thijs Kinkhorst. - Closes: #368046 + * stop using capitals, minor fixes, language fixes. + Thanks, Thijs Kinkhorst, Colin Tuckley, Russ Allbery. + Closes: #368046, #378929, #361744 -- Andreas Barth Sat, 11 Nov 2006 10:55:44 -0700 diff --git a/developers-reference.sgml b/developers-reference.sgml index de70776..470e45c 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -7,7 +7,7 @@ %dynamicdata; - + @@ -175,7 +175,7 @@ available in .

Before you decide to register with &debian-formal;, you will need to read all the information available at the . It describes exactly the +name="New Maintainer's Corner">. It describes in detail the preparations you have to do before you can register to become a Debian developer. @@ -190,7 +190,7 @@ Manifesto"> would also be a good idea. The process of registering as a developer is a process of verifying your identity and intentions, and checking your technical skills. As the number of people working on &debian-formal; has grown to over -&number-of-maintainers; people and our systems are used in several +&number-of-maintainers; and our systems are used in several very important places, we have to be careful about being compromised. Therefore, we need to verify new maintainers before we can give them accounts on our servers and let them upload packages. @@ -216,11 +216,11 @@ a Debian Developer close to you. alternative ways to pass the ID check may be permitted as an absolute exception on a case-by-case-basis. See the -for more informations.) +for more information.)

If you do not have an OpenPGP key yet, generate one. Every developer -needs a OpenPGP key in order to sign and verify package uploads. You +needs an OpenPGP key in order to sign and verify package uploads. You should read the manual for the software you are using, since it has much important information which is critical to its security. Many more security failures are due to human error than to software failure @@ -267,7 +267,7 @@ modern OpenPGP software does that automatically, but if you have an older key you may have to manually add those signatures.

-If your public key isn't on public key servers such as &pgp-keyserv;, +If your public key isn't on a public key server such as &pgp-keyserv;, please read the documentation available at . That document contains instructions on how to put your key on the @@ -369,10 +369,10 @@ You don't have to track the pre-vote discussions, as the secretary will issue several calls for votes on &email-debian-devel-announce; (and all developers are expected to be subscribed to that list). Democracy doesn't work well if people don't take part in the vote, which is why we encourage -all developers to vote. Voting is conducted via GPG-signed/encrypted emails +all developers to vote. Voting is conducted via GPG-signed/encrypted email messages.

-The list of all the proposals (past and current) is available on the +The list of all proposals (past and current) is available on the page, along with information on how to make, second and vote on proposals. @@ -381,14 +381,14 @@ information on how to make, second and vote on proposals.

It is common for developers to have periods of absence, whether those are planned vacations or simply being buried in other work. The important thing -to notice is that the other developers need to know that you're on vacation +to notice is that other developers need to know that you're on vacation so that they can do whatever is needed if a problem occurs with your packages or other duties in the project.

Usually this means that other developers are allowed to NMU (see -) your package if a big problem (release critical bugs, +) your package if a big problem (release critical bug, 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 +nothing as critical as that, but it's still appropriate to let others know that you're unavailable.

In order to inform the other developers, there are two things that you should do. @@ -440,7 +440,7 @@ you need to take care of — the so-called release-critical bugs (RC bugs). All bug reports that have severity critical, grave or serious are considered to have an impact on whether the package can be released in the next stable release of Debian. -Those bugs can delay the Debian release +These bugs can delay the Debian release and/or can justify the removal of a package at freeze time. That's why these bugs need to be corrected as quickly as possible.

@@ -700,7 +700,7 @@ an email to &email-ftpmaster;, but also see the procedures in The non-US server non-us.debian.org was discontinued with the release of sarge. The pseudo-package nonus.debian.org -stil exists for now. +still exists for now. The www-master server

@@ -756,7 +756,7 @@ the Debian account that should own the CVS root area, and why you need it. chroots to different distributions

On some machines, there are chroots to different distributions available. -You can use them like +You can use them like this: vore% dchroot unstable @@ -887,8 +887,8 @@ fields of packages. Architectures

-In the first days, the Linux kernel was only available for the Intel -i386 (or greater) platforms, and so was Debian. But when Linux became +In the first days, the Linux kernel was only available for Intel +i386 (or greater) platforms, and so was Debian. But as Linux became more and more popular, the kernel was ported to other architectures, too.

@@ -931,7 +931,7 @@ outside of Debian, there is just one .tar.gz file which contains the sources of the program. If a package is distributed elsewhere too, the .orig.tar.gz file stores the so-called upstream source code, that is the source code that's -distributed from the upstream maintainer (often the author of +distributed by the upstream maintainer (often the author of the software). In this case, the .diff.gz contains the changes made by the Debian maintainer.

@@ -1090,7 +1090,7 @@ Every released Debian distribution has a code name: Debian 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; Debian 3.1, "sarge"; -Debian (number needs to be determined), "etch". +Debian 4.0, "etch". There is also a ``pseudo-distribution'', called `sid', which is the current `unstable' distribution; since packages are moved from `unstable' to `testing' as they approach stability, `sid' itself is never released. @@ -1182,7 +1182,7 @@ accessible at until it is really installed in the Debian archive. This happens only once a day -(and is also called `dinstall run' for historical reasons); +(and is also called the `dinstall run' for historical reasons); the package is then removed from incoming and installed in the pool along with all the other packages. Once all the other updates (generating new @@ -1572,8 +1572,8 @@ distribution, testing status and much more including links to any other useful information.

It is a good idea to look up your own data regularly so that -you don't forget any open bug, and so that you don't forget which -packages are under your responsibility. +you don't forget any open bugs, and so that you don't forget which +packages are your responsibility. Debian *Forge: Alioth

@@ -1876,7 +1876,7 @@ and the Debian package . Uploading to non-US

-Note: non-us was discontinued with release of sarge. +Note: non-us was discontinued with the release of sarge. Delayed uploads @@ -1914,7 +1914,7 @@ The scp queues on ftp-master, and security are mostly unusable due to the login restrictions on those hosts.

The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are -currently down. Work is underway to resurrect those. +currently down. Work is underway to resurrect them.

The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and ftp.chiark.greenend.org.uk are down permanently, and will not be @@ -1969,7 +1969,7 @@ for your next upload, or else you may wish to make a change in the override file.

To alter the actual section that a package is put in, you need to -first make sure that the debian/control in your package +first make sure that the debian/control file in your package is accurate. Next, send an email &email-override; or submit a bug against ftp.debian.org requesting that the section or priority for your package be changed from the old section or @@ -2001,7 +2001,7 @@ and tags, marking bugs as forwarded, and other issues. Operations such as reassigning bugs to other packages, merging separate bug reports about the same issue, or reopening bugs when they are prematurely closed, are handled using the so-called control mail server. -All of the commands available in this server are described in the +All of the commands available on this server are described in the . Monitoring bugs @@ -2039,7 +2039,7 @@ contact the submitter and to record your mail within the bug log (that means you don't need to send a copy of the mail to 123@&bugs-host;).

-If you get a bug which mentions "FTBFS", that means "Fails to build +If you get a bug which mentions "FTBFS", this means "Fails to build from source". Porters frequently use this acronym.

Once you've dealt with a bug report (e.g. fixed it), mark it as @@ -2119,7 +2119,7 @@ details on the technicalities of the merge command and its relative, the unmerge command, see the BTS control server documentation. The bug submitter may have forgotten to provide some information, in which -case you have to ask them the required information. You may use the +case you have to ask them for the required information. You may use the moreinfo tag to mark the bug as such. Moreover if you can't reproduce the bug, you tag it unreproducible. Anyone who can reproduce the bug is then invited to provide more information @@ -2133,8 +2133,9 @@ upstream problem, you have to forward it to the upstream author. Forwarding a bug is not enough, you have to check at each release if the bug has been fixed or not. If it has, you just close it, otherwise you have to remind the author about it. If you have the required skills -you can prepare a patch that fixes the bug and that you send at the -same time to the author. Make sure to send the patch to the BTS and to +you can prepare a patch that fixes the bug and +send it to the author at the same time. +Make sure to send the patch to the BTS and to tag the bug as patch. If you have fixed a bug in your local copy, or if a fix has been @@ -2196,14 +2197,16 @@ The same applied to the tag fixed-in-experimental.

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 reopen XXX command to +wrongly closed bugs, send a reopen XXX command to the bug tracking system's control address, &email-bts-control;. To close any remaining bugs that were fixed by your upload, email the .changes file to XXX-done@&bugs-host;, -where XXX is your bug number, and -put "Version: XXX" and an empty line as the first two lines -of the body of the email -to mark the first version where this bug has been closed. +where XXX is the bug number, and +put "Version: YYY" and an empty line as the first two lines +of the body of the email, +where YYY is the first version +where the bug has been fixed. +

Bear in mind that it is not obligatory to close bugs using the changelog as described above. If you simply want to close bugs that @@ -2222,7 +2225,7 @@ For general information on how to write your changelog entries, see Due to their sensitive nature, security-related bugs must be handled carefully. The Debian Security Team exists to coordinate this activity, keeping track of outstanding security problems, helping -maintainers with security problems or fix them themselves, sending +maintainers with security problems or fixing them themselves, sending security advisories, and maintaining security.debian.org. @@ -2238,7 +2241,7 @@ packages for stable; the security team will do that. Useful information includes, for example: - What versions of the package are known to be affected by the + Which versions of the package are known to be affected by the bug. Check each version that is present in a supported Debian release, as well as testing and unstable. @@ -2267,7 +2270,7 @@ case depends on the nature of the problem and corresponding fix, and whether it is already a matter of public knowledge.

-There are a few ways developers can learn of a security problem: +There are several ways developers can learn of a security problem: they notice it on a public forum (mailing list, web site, etc.) @@ -2287,7 +2290,7 @@ There are a few ways developers can learn of a security problem: If the problem is severe, it is preferable to share the information with other vendors and coordinate a release. The security team keeps - contacts with the various organizations and individuals and can take + in contact with the various organizations and individuals and can take care of that. @@ -2484,9 +2487,8 @@ be fixes for security problems that cannot be disclosed yet.

If a member of the security team accepts a package, it will be -installed on security.debian.org as well as the proper -distribution-proposed-updates on ftp-master or in the non-US -archive. +installed on security.debian.org as well as proposed for the proper +distribution-proposed-updates on ftp-master. Moving, removing, renaming, adopting, and orphaning @@ -2494,7 +2496,7 @@ archive.

Some archive manipulation operations are not automated in the Debian upload process. These procedures should be manually followed by -maintainers. This chapter gives guidelines in what to do in these +maintainers. This chapter gives guidelines on what to do in these cases. Moving packages @@ -2541,7 +2543,7 @@ for the packages that are no longer created to be removed. Such packages will be removed when the new package structure has been uploaded into unstable and when no package in testing depends on it.

-You also have to detail the reasons justifying that request. This is to +You also have to detail the reasons justifying the request. This is to avoid unwanted removals and to keep a trace of why a package has been removed. For example, you can provide the name of the package that supersedes the one to be removed. @@ -2566,7 +2568,7 @@ Once the package has been removed, the package's bugs should be handled. They should either be reassigned to another package in the case where the actual code has evolved into another package (e.g. libfoo12 was removed because libfoo13 supersedes it) or closed if the -software is simply no more part of Debian. +software is simply no longer part of Debian. Removing packages from Incoming

@@ -2604,8 +2606,8 @@ mirror network. Orphaning a package

-If you can no longer maintain a package, you need to inform the others -about that, and see that the package is marked as orphaned. +If you can no longer maintain a package, you need to inform others, +and see that the package is marked as orphaned. You should set the package maintainer to Debian QA Group &orphan-address; and submit a bug report against the pseudo package wnpp. The bug report should be @@ -2628,7 +2630,7 @@ More information is on the . Adopting a package

-A list of packages in need of a new maintainer is available at in the +A list of packages in need of a new maintainer is available in the . If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned @@ -2875,7 +2877,7 @@ blessing or status, so buyer beware. Porting infrastructure and automation

-There is infrastructure and several tools to help automate the package +There is infrastructure and several tools to help automate package porting. This section contains a brief overview of this automation and porting to these tools; see the package documentation or references for full information.

@@ -2932,7 +2934,7 @@ general interest (for instance, a flavor of Debian built with gcc bounds checking). It will also enable Debian to recompile entire distributions quickly.

-The buildds admins of each arch can be contacted by the mail address +The buildds admins of each arch can be contacted at the mail address $arch@buildd.debian.org. When your package is not portable @@ -2997,7 +2999,7 @@ that too is strictly speaking a binary NMU. See for some more information.

The main reason why NMUs are done is when a -developer needs to fix another developer's packages in order to +developer needs to fix another developer's package in order to address serious problems or crippling bugs or when the package maintainer is unable to release a fix in a timely fashion. @@ -3023,7 +3025,7 @@ NMUs which fix important, serious or higher severity bugs are encouraged and accepted. You should endeavor to reach the current maintainer of the package; they might be just about to upload a fix for the problem, or have a better -solution present. +solution.

NMUs should be made to assist a package's maintainer in resolving bugs. Maintainers should be thankful for that help, and NMUers should respect @@ -3127,11 +3129,11 @@ If you upload a package to testing or stable, sometimes, you need to Source NMUs must have a new changelog entry

-A non-maintainer doing a source NMU must create a changelog entry, +Anyone who is doing a source NMU must create a changelog entry, describing which bugs are fixed by the NMU, and generally why the NMU was required and what it fixed. The changelog entry will have the -non-maintainer's email address in the log entry and the NMU version -number in it. +email address of the person who uploaded it in the log entry +and the NMU version number in it.

By convention, source NMU changelog entries start with the line @@ -3168,7 +3170,7 @@ changes in the NMU are incorporated officially into the package by the official package maintainer.

Also, after doing an NMU, you have to send -that information to the existing bugs that are fixed by your NMU, +the information to the existing bugs that are fixed by your NMU, including the unified diff. Alternatively you can open a new bug and include a patch showing all the changes you have made. @@ -3190,7 +3192,7 @@ please reopen the relevant bug reports.

Source NMU packages are built normally. Pick a distribution using the same rules as found in , follow the other -prescriptions in . +instructions in .

Make sure you do not change the value of the maintainer in the debian/control file. Your name as given in the NMU entry of @@ -3212,7 +3214,7 @@ entry of your next upload.

In any case, you should not be upset by the NMU. An NMU is not a personal attack against the maintainer. It is a proof that -someone cares enough about the package and that they were willing to help +someone cares enough about the package that they were willing to help you in your work, so you should be thankful. You may also want to ask them if they would be interested in helping you on a more frequent basis as co-maintainer or backup maintainer @@ -3225,13 +3227,12 @@ package to see if it has been orphaned. The current list of orphaned packages which haven't had their maintainer set correctly is available at . If you perform an NMU on an improperly orphaned package, please set the maintainer to ``Debian QA Group -<packages@qa.debian.org>''. Also, the bugs are closed in that case, -and not only marked fixed. +<packages@qa.debian.org>''. Who can do an NMU

-Only official, registered Debian maintainers can do binary or source -NMUs. An official maintainer is someone who has their key in the +Only official, registered Debian Developers can do binary or source +NMUs. A Debian Developer is someone who has their key in the Debian key ring. Non-developers, however, are encouraged to download the source package and start hacking on it to fix problems; however, rather than doing an NMU, they should just submit worthwhile patches @@ -3264,7 +3265,7 @@ compile for their target architecture; that would be considered a source NMU rather than a binary-only NMU. As you can see, we don't distinguish in terminology between porter NMUs and non-porter NMUs.

-Both classes of NMUs, source and binary-only, can be lumped by the +Both classes of NMUs, source and binary-only, can be lumped under the term ``NMU''. However, this often leads to confusion, since most people think ``source NMU'' when they think ``NMU''. So it's best to be careful: always use ``binary NMU'' or ``binNMU'' for binary-only @@ -3277,7 +3278,7 @@ NMUs. "Collaborative maintenance" is a term describing the sharing of Debian package maintenance duties by several people. This collaboration is almost always a good idea, since it generally results in higher quality and -faster bug fix turnaround time. It is strongly recommended that +faster bug fix turnaround times. It is strongly recommended that packages with a priority of Standard or which are part of the base set have co-maintainers.

@@ -3313,7 +3314,7 @@ should subscribe themselves to the appropriate source package.

-Collaborative maintenance can often be further eased with the use of +Collaborative maintenance can often be further eased by the use of tools on Alioth (see ). @@ -3366,7 +3367,7 @@ in testing; The packages on which it depends must either be available in testing or they must be accepted into testing at the same time (and they will -if they fulfill all the necessary criteria); +be if they fulfill all the necessary criteria);

To find out whether a package is progressing into testing or not, see the @@ -3495,8 +3496,9 @@ If you are interested in details, this is how britney works: 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, the release managers have hammers -of any size to force britney to consider a package. (Also, the base +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.) @@ -3710,7 +3712,7 @@ documentation and examples (in /usr/share/doc/dpatch). A single source package will often build several binary packages, either to provide several flavors of the same software (e.g., the vim source package) or to make several small -packages instead of a big one (e.g., if the user can install only the +packages instead of a big one (e.g., so the user can install only the subset needed, and thus save some disk space).

The second case can be easily managed in debian/rules. @@ -3985,7 +3987,7 @@ just mention this fact in your own changelog entry. Common errors in changelog entries

-The following examples demonstrate some common errors or example of +The following examples demonstrate some common errors or examples of bad style in changelog entries.

@@ -4217,7 +4219,7 @@ good start). Avoid changing templates too often. Changing templates text induces more work to translators which will get their translation "fuzzied". If you plan changes to your original templates, please contact -translators. Most active translators are very reactive and getting +translators. Most active translators are very responsive and getting their work included along with your modified templates will save you additional uploads. If you use gettext-based templates, the translator's name and e-mail addresses are mentioned in the po files @@ -5131,18 +5133,20 @@ haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder.

There is a simple system (the MIA database) in which information about -maintainers who are deemed Missing In Action are recorded. When a member of the +maintainers who are deemed Missing In Action is recorded. +When a member of the QA group contacts an inactive maintainer or finds more information about one, this is recorded in the MIA database. This system is available in /org/qa.debian.org/mia on the host qa.debian.org, and can be queried with a tool known as mia-query. Use mia-query --help to see how to query the database. If you find that no information has been recorded -about an inactive maintainer already, or that you can add more information, +about an inactive maintainer yet, or that you can add more information, you should generally proceed as follows.

-The first step is to politely contact the maintainer, and wait for a -response for a reasonable time. It is quite hard to define "reasonable +The first step is to politely contact the maintainer, +and wait a reasonable time for a response. +It is quite hard to define "reasonable time", but it is important to take into account that real life is sometimes very hectic. One way to handle this would be to send a reminder after two weeks. @@ -5155,7 +5159,7 @@ about the maintainer in question as possible. This includes: The "echelon" information available through the , - which indicates when the developer last has posted to + which indicates when the developer last posted to a Debian mailing list. (This includes uploads via debian-*-changes lists.) Also, remember to check whether the maintainer is marked as "on vacation" in the database. @@ -5184,16 +5188,16 @@ is aware of the whereabouts of the missing maintainer. Please Cc: the person in question.

Once you have gathered all of this, you can contact &email-mia;. -People on this alias will use the information you provided in order to +People on this alias will use the information you provide 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 +packages of the maintainer. If a package has been NMUed, they might prefer to contact the NMUer before orphaning the package — perhaps the person who has done the NMU is interested in the package.

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 +seriously ill or might even have died — you do not know who may be on the receiving side. Imagine how a relative will feel if they read the e-mail of the deceased and find a very impolite, angry and accusing message!

@@ -5355,7 +5359,7 @@ For web pages, each l10n team has access to the relevant CVS, and the statistics are available from the Central Debian translation statistics site.

For general documentation about Debian, the process is more or less the same -than for the web pages (the translators have access to the CVS), but there are +as for the web pages (the translators have access to the CVS), but there are no statistics pages.

For package-specific documentation (man pages, info documents, other formats), @@ -5454,9 +5458,9 @@ running. As a maintainer, never edit the translations in any way (even to reformat the -layout) without asking to the corresponding l10n mailing list. You risk for -example to break the encoding of the file by doing so. Moreover, what you -consider as an error can be right (or even needed) in the given language. +layout) without asking on the corresponding l10n mailing list. You risk for +example breaksing the encoding of the file by doing so. Moreover, what you +consider an error can be right (or even needed) in the given language. As a translator, if you find an error in the original text, make sure to report it. Translators are often the most attentive readers of a given text, and if -- 2.30.2