X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=0c7c09b4ac8204a83ef62896ef9842666f25b6b9;hb=cae66cec74d26468dd4f4c31516ed617a9f9a616;hp=f64955c1f615143efec57b1d292507eec09b0037;hpb=4d3846471cf785e8bc5623e71adcb46bba604efe;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index f64955c..0c7c09b 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -129,7 +129,7 @@ Debian GNU/Linux has grown to over &number-of-maintainers; people 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 -letting them upload packages. +let them upload packages.
Registration requires that the following information be sent in
appropriate steps described at
You have to keep the information available there up to date.
@@ -309,10 +309,14 @@ 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
+do if any problem occurs. Be aware that some people don't care for vacation
+notices and don't want to read them; you should prepend "[VAC] " to the
+subject of your message so that it can be easily filtered.
+
+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.
+to remove the ``on vacation'' flag when you come back!
@@ -364,6 +368,22 @@ id="orphaning">). 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;).
+
+If you notice that a package is lacking maintenance, you should
+make sure the maintainer is active and will continue to work on
+their packages. Try contacting them yourself.
+
+If you do not get a reply after a few weeks you should collect all
+useful information about this maintainer. Start by logging in to
+the
+Send all this information to &email-debian-qa;, in order to let the
+QA people do whatever is needed.
+
If you choose to leave the Debian project, you should make sure you do
@@ -883,8 +903,8 @@ You should set the subject of the bug to ``ITP: foo
-- short description'', substituting the name of the new
package for foo. The severity of the bug report must be set
to wishlist. If you feel it's necessary, send a copy to
-&email-debian-devel; by putting the address in the X-Debbugs-CC: header
-of the message (no, don't use CC:, because that way the message's subject
+&email-debian-devel; by putting the address in the X-Debbugs-CC: header
+of the message (no, don't use CC:, because that way the message's subject
won't indicate the bug number).
Please include a Closes: bug#nnnnn entry on the
@@ -915,11 +935,38 @@ better feel of what is going on, and what is new, in the project.
+
+Before you upload your package, you should do basic testing on it. At
+a minimum, you should try the following activities (you'll need to
+have an older version of the same Debian package around):
+
+Normally, a package should not be uploaded if it causes lintian
+to emit errors (they will start with E).
+
+For more information on
When a package is uploaded to the Debian FTP archive, it must be
accompanied by a .changes file, which gives directions to the
@@ -934,29 +981,10 @@ All of these fields are mandatory for a Debian upload. See the list
of control fields in the
-Notably, the Distribution field, which originates from the
-
-You should avoid combining `stable' with others because of potential
-problems with library dependencies (for your package and for the package
-built by the build daemons for other architecture).
-See for more information on when and how to
-upload to stable.
+
The first time a version is uploaded which corresponds to a particular
upstream version, the original source tar file should be uploaded and
@@ -979,6 +1007,32 @@ is some reason why this is not the case, the new version of the
original source should be uploaded, possibly by using the -sa
flag.
+
+
+The Distribution field, which originates from the first line of
+the
+There are four possible values for this field: `stable', `unstable',
+`frozen', and `experimental'. Normally, packages are uploaded into
+unstable.
+
+These values can be combined, but only a few combinations make sense.
+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 uploading to
+frozen.
+
+You should avoid combining `stable' with others because of potential
+problems with library dependencies (for your package and for the package
+built by the build daemons for other architecture).
+See for more information on when and how to
+upload to stable.
+
+It never makes sense to combine the experimental distribution
+with anything else.
+
The Debian freeze is a crucial time for Debian. It is our chance to
@@ -1058,36 +1112,7 @@ inclusion.
-
-Before you upload your package, you should do basic testing on it. At
-a minimum, you should try the following activities (you'll need to
-have an older version of the same Debian package around):
-
-Normally, a package should not be uploaded if it causes lintian
-to emit errors (they will start with E).
-
-For more information on
+
-
-
-
+