From b83d312382f9094ae56d7024f96ee2e9986a4f42 Mon Sep 17 00:00:00 2001 From: joy Date: Tue, 19 Dec 2000 00:04:59 +0000 Subject: [PATCH] =?utf8?q?replaced=20evil=20latin1-only=20=C2=AB=C2=BB=20q?= =?utf8?q?uotation=20marks,=20replaced=20mentions=20of=20important=20sever?= =?utf8?q?ity=20(in=20RCB=20context)=20with=20serious=20severity,=20some?= =?utf8?q?=20details=20fixed?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1074 313b444b-1b9f-4f58-a734-7bb04f332e8d --- developers-reference.sgml | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/developers-reference.sgml b/developers-reference.sgml index 380a989..4149d20 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -310,9 +310,9 @@ In order to inform the other developers, there's two things that you should do. First send a mail to &email-debian-private; giving the period of time when you will be on vacation. You can also give some special instructions on what to do if any problem occurs. Next you should update your information -available in the Debian LDAP database and mark yourself as « on vacation » +available in the Debian LDAP database and mark yourself as ``on vacation'' (this information is only accessible to debian developers). Don't forget -to remove the « on vacation » flag when you come back. +to remove the ``on vacation'' flag when you come back. Coordination With Upstream Developers

@@ -336,9 +336,9 @@ need, always try not to fork from the upstream sources. Managing Release Critical Bugs

-Release Critical Bugs (RCB) are the bugs of severity -« critical », « grave » and -« important ». Those bugs can delay the Debian release +Release Critical Bugs (RCB) are all bugs that have severity +critical, grave or serious. +Those bugs can delay the Debian release and/or can justify the removal of a package at freeze time. That's why those bugs needs to be corrected as fast as possible. You must be aware that some developers who are part of the for a list. Cross-posting (sending the same message to multiple lists) is discouraged.

-&email-debian-private; is a special mailing lists for private +&email-debian-private; is a special mailing list for private discussions amongst Debian developers. It is meant to be used for posts which for whatever reason should not be published publically. As such, it is a low volume list, and users are urged not to use @@ -976,15 +976,15 @@ some guidelines: Fixes for bugs of severity critical, grave, or -important severity are always allowed for those packages that +serious severity are always allowed for those packages that must exist in the final release -critical, grave, and important bug fixes -are only allowed for non-necessary packages if they don't add any new +critical, grave, and serious bug fixes are +allowed for non-necessary packages but only if they don't add any new features -normal bug fixes are allowed (though discouraged) on all packages if -and only if there are no new features +important, normal and minor bug fixes are allowed (though discouraged) +on all packages if and only if there are no new features wishlist fixes are not allowed (they are, after all, not really bugs) @@ -1287,7 +1287,7 @@ cannot be reached in time, the Security Manager may upload a fixed package (i.e., do a source NMU).

During the release freeze (see ), NMUs which -fix important or higher severity bugs are encouraged and accepted. +fix serious or higher severity bugs are encouraged and accepted. Even during this window, however, you should endeavor to reach the current maintainer of the package; they might be just about to upload a fix for the problem. As with any source NMU, the guidelines found @@ -1586,7 +1586,7 @@ the porting effort, at the discretion of the porter group. (Remember, none of this is Policy, just mutually agreed upon guidelines.)

Secondly, porters doing source NMUs should make sure that the bug they -submit to the BTS should be of severity `important' or greater. This +submit to the BTS should be of severity `serious' or greater. This ensures that a single source package can be used to compile every supported Debian architecture by release time. It is very important that we have one version of the binary and source package for all -- 2.30.2