From ce93b43b79832af61460f2036a8abe5915780cfa Mon Sep 17 00:00:00 2001 From: aph Date: Mon, 17 Apr 2000 02:24:28 +0000 Subject: [PATCH] changes from Raphael Hertzog , 25 Mar 2000 git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@943 313b444b-1b9f-4f58-a734-7bb04f332e8d --- common.ent | 8 ++- constitution.en.html | 25 +------- developers-reference.sgml | 129 +++++++++++++++++++++++++++++++++----- 3 files changed, 120 insertions(+), 42 deletions(-) diff --git a/common.ent b/common.ent index 612e8c8..1e75a3c 100644 --- a/common.ent +++ b/common.ent @@ -9,7 +9,7 @@ - + @@ -45,6 +45,9 @@ + + + @@ -76,6 +79,9 @@ debian-private@&lists-host;"> debian-policy@&lists-host;"> debian-policy@&lists-host;"> +debian-qa@&lists-host;"> +debian-release@&lists-host;"> +debian-email@&lists-host;"> new-maintainer@debian.org"> keyring-maint@debian.org"> diff --git a/constitution.en.html b/constitution.en.html index adcd193..2d76d31 100644 --- a/constitution.en.html +++ b/constitution.en.html @@ -11,25 +11,6 @@ - - - - - - - -

Debian Constitution

Constitution for the Debian Project (v1.0)

1. Introduction

@@ -750,10 +731,6 @@ does not form part of the constitution. It may be used only to aid interpretation in cases of doubt.

Back to the Debian GNU/Linux homepage. -

-See the Debian contact page for information on contacting us.

-Last Modified: Thu, Dec 10 03:36:32 UTC 1998
-Copyright © 1997-1999 SPI; See license terms +Copyright © 1997-1999 SPI; See license terms diff --git a/developers-reference.sgml b/developers-reference.sgml index 40e1987..21efdba 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -258,7 +258,22 @@ Those who prefer one-on-one help (e.g., via private email) should also post to that list and an experienced developer will volunteer to help. - Maintaining Your Debian Information + Debian Developer's Duties + + Maintaining Your Debian Information +

+There's a LDAP database containing many informations concerning all +developers, you can access it at . You can +update your password (this password is propagated to most of the machines +that are accessible to you), your adress, your country, the latitude and +longitude from the point where you live, phone and fax numbers, your +preferred shell, your IRC nickname, your web page and the email that +you're using as alias for your debian.org email. Most of the information +is not accessible to the public, for more details about this +database, please read its online documentation that you can find +here : . +

+You have to keep the information available there up to date. Maintaining Your Public Key

@@ -276,6 +291,67 @@ routines discussed in apply. You can find a more in-depth discussion of Debian key maintenance in the documentation for the debian-keyring package. + Going On Vacation Gracefully +

+Most of the developers take vacation, usually this means that they can't +work for Debian and they can't be reached by email if any problem occurs. +The other developers need to know that you're on vacation so that they'll +do whatever is needed when such a problem occurs. Usually this means that +other developers are allowed to NMU your package if a big problem (release +critical bugs, security update, ...) occurs while you're on vacation. +

+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 » +(this information is only accessible to debian developers). Don't forget +to remove the « on vacation » flag when you come back. + + Coordination With Upstream Developers +

+A big part of your job as Debian maintainer will be to stay in contact +with the upstream developers since you'll have to share information that +you get from the Bug Tracking System. It's not your job to fix non-Debian +specific bugs so you have to forward the bugs to the upstream developers +(of course, if you are able to fix them, you can ...). This way the bug +may be corrected when the next upstream version comes out. From time to +time, you may get a patch attached to a bug report, you have to send the +patch upstream and make sure that it gets included (if the authors accept +the proposed fix). If you need to modify the upstream sources in order to +build a policy conformant package, then you should propose a nice fix +to the upstream developers which can be included so that you won't have to +modify the sources of the next upstream version. Whatever changes you +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 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 effort are following +those bugs and try to help you each time they can. But if you can't +fix such bugs within 2 weeks, you should either ask for help by sending a +mail to the Quality Assurance (QA) group (&email-debian-qa;) or +justify yourself and gives your plan to fix it by sending a mail to the +concerned bug report. Otherwise people from the QA group may want to do a +Non Maintainer Upload (NMU) after trying to contact you (they might wait +not as long as usually before they do their NMU if they have seen no +recent activity from you on the BTS). + + Quality Assurance Effort +

+Even if there is a dedicated group of people for Quality Assurance, QA is +not reserved to them. You can participate to this effort by keeping your +packages as bug free as possible, as lintian-clean (see ) as possible. If you think that it's quite impossible, +then you should consider orphaning (see ) some of your +packages so that you can do a good job with the other packages that you +maintain. Alternatively you may ask the help of other people in order to +catch up the backlog of bugs that you have (you can ask for help on +&email-debian-qa; or &email-debian-devel;). Retiring Gracefully

@@ -332,6 +408,11 @@ As such, it is a low volume list, and users are urged not to use &email-debian-private; unless it is really necessary. Moreover, do not forward email from that list to anyone.

+&email-debian-email; is a special mailing list used as a grab-bag +for Debian related correspondence such as contacting upstream authors +about licenses, bugs, etc. or discussing the project with others where it +might be useful to have the discussion archived somewhere. +

As ever on the net, please trim down the quoting of articles you're replying to. In general, please adhere to the usual conventions for posting messages. @@ -825,12 +906,16 @@ put `stable unstable' in the changelog's Distribution field. Or, if Debian has been frozen, and you want to get a bug-fix release into frozen, you would set the distribution to `frozen unstable'. (See for -more information on when to upload to frozen.) Note that -setting the distribution to `stable' means that the package will be -placed into the proposed-updates directory of the Debian -archive for further testing before it is actually included in -stable. Also note that it never makes sense to combine the -experimental distribution with anything else. +more information on when to upload to frozen.) Note that it +never makes sense to combine the experimental distribution with +anything else. Also note that setting the distribution to `stable' means +that the package will be placed into the proposed-updates +directory of the Debian archive for further testing before it is actually +included in stable. The Release Team (which can be reached at +&email-debian-release;) will decide if your package can be included in +stable, therefore if your changelog entry is not clear enough, you may +want to explain them why you uploaded your package to stable by sending +them a short explication.

The first time a version is uploaded which corresponds to a particular upstream version the original source tar file should be uploaded and @@ -953,7 +1038,10 @@ defaults for uploading via ftp to master, chiark, and erlangen. It can also be configured to use ssh. See and for more information. - +

+After uploading your package, you can check how dinstall will +process it by running dinstall on your changes file: +~maor/dinstall/dinstall -n foo.changes Uploading to pandora (non-us)

@@ -967,7 +1055,11 @@ same account which works on master. The program dupload comes with support for uploading to pandora; please refer to the documentation that comes with the program for details. - +

+Just as for an upload to master, you can check your upload with : +/org/non-us.debian.org/scripts/dinstall/dinstall -n foo.changes + + Uploads via chiark

If you have a slow network connection to master, there are @@ -1031,22 +1123,25 @@ anonymous FTP to . Announcing package uploads

When a package is uploaded an announcement should be posted to one of -the ``debian-changes'' lists. The announcement should give the -(source) package name and version number, and a very short summary of -the changes, in the Subject field, and should contain the -PGP-signed .changes file. Some additional explanatory text -may be added before the start of the .changes file. +the ``debian-changes'' lists. This is now done automatically by dinstall +when it runs (usually once a day), you just need to use a recent +dpkg-dev (>= 1.4.1.2). Before that, +dupload was used to send those announcements, please make +sure that you configured your dupload to no more send those +announcements (check its documentation and look for dinstall_runs). The +mail generated by dinstall will contain the PGP/GPG signed .changes files +that you uploaded with your package.

If a package is released with the Distribution: set to `stable', the announcement is sent to &email-debian-changes;. If a package is released with Distribution: set to `unstable', -`experimental', or `frozen' (when present), the announcement should be +`experimental', or `frozen' (when present), the announcement will be posted to &email-debian-devel-changes; instead.

On occasion, it is necessary to upload a package to both the stable and unstable distributions; this is done by putting both distributions in the Distribution: line. In -such a case the upload announcement should go to both of the above +such a case the upload announcement will go to both of the above mailing lists.

The dupload program is clever enough to determine for itself -- 2.30.2