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 . +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! Coordination With Upstream Developers

@@ -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;). + Dealing with unreachable maintainers +

+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 +and doing a full search to check whether the maintainer is on vacation +and when they were last seen. Collect any important package names +they maintain and any Release Critical bugs filled against them. +

+Send all this information to &email-debian-qa;, in order to let the +QA people do whatever is needed. + Retiring Gracefully

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. + Checking the package prior to upload +

+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): + + +Install the package and make sure the software works, or upgrade the +package from an older version to your new version if a Debian package +for it already exists. + +Run lintian over the package. You can run +lintian as follows: lintian -v +package-version.changes. This will check the source +package as well as the binary package. If you don't understand the +output that lintian generates, try adding the -i +switch, which will cause lintian to output a very verbose +description of the problem. +

+Normally, a package should not be uploaded if it causes lintian +to emit errors (they will start with E). +

+For more information on lintian, see . + +Downgrade the package to the previous version (if one exists) — this +tests the postrm and prerm scripts. + +Remove the package, then reinstall it. + - Uploading a package - - Generating the changes file + Generating the changes file

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 for the contents of these fields. You can close bugs automatically using the Description field, see . Only the Distribution field is -discussed in this section, since it relates to the archive maintenance -policies. +id="upload-bugfix">. - Picking a distribution -

-Notably, the Distribution field, which originates from the -debian/changelog file, indicates which distribution the -package is intended for. There are four possible values for this -field: `stable', `unstable', `frozen', or `experimental'; these values -can also be combined. 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 it -never makes sense to combine the experimental distribution with -anything else. -

-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 original source tarball

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. + + Picking a distribution +

+The Distribution field, which originates from the first line of +the debian/changelog file, indicates which distribution the +package is intended for. +

+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. + Uploading to frozen

The Debian freeze is a crucial time for Debian. It is our chance to @@ -1058,36 +1112,7 @@ inclusion. - Checking the package prior to upload -

-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): - - -Install the package and make sure the software works, or upgrade the -package from an older version to your new version if a Debian package -for it already exists. - -Run lintian over the package. You can run -lintian as follows: lintian -v -package-version.changes. This will check the source -package as well as the binary package. If you don't understand the -output that lintian generates, try adding the -i -switch, which will cause lintian to output a very verbose -description of the problem. -

-Normally, a package should not be uploaded if it causes lintian -to emit errors (they will start with E). -

-For more information on lintian, see . - -Downgrade the package to the previous version (if one exists) — this -tests the postrm and prerm scripts. - -Remove the package, then reinstall it. - - + Uploading a package Uploading to ftp-master