From 48eabefe4e4c1b1ebc426cecf3941bdfa50f4f41 Mon Sep 17 00:00:00 2001 From: aph Date: Mon, 28 Sep 1998 02:39:19 +0000 Subject: [PATCH] Fix instructions for new maintainers, incorporating the actual text sent to prospective new maintainers. Improve this text a bit for readability, coverage, and organization. Significant changes were patched back to the new-maintainers group, if they care to use them. (closes Bug#26948) Add an introductory "Scope" section which helps delineate what should and should not be included in this Reference. Add discussion of the "experimental" distribution, culled from an email from Guy Maor on debian-devel. Point to doc-debian's mailing list instructions where relevant. Made references to online documentation into URLs where possible. Little corrections here and there. git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@655 313b444b-1b9f-4f58-a734-7bb04f332e8d --- developers-reference.sgml | 462 +++++++++++++++++++++++++++----------- 1 file changed, 334 insertions(+), 128 deletions(-) diff --git a/developers-reference.sgml b/developers-reference.sgml index fc42aff..eeb6a26 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -7,9 +7,8 @@ @@ -44,117 +43,180 @@ writing to the Free Software Foundation, Inc., 59 Temple Place - Suite - Applying to Become a Maintainer + Scope of This Document +

+The purpose of this document is to provide an overview of the +processes and resources used by Debian developers. +

+The processes discussed within include how to become a maintainer +(); how to upload new packages (); how and when to do interim releases of other +maintainer's packages (); how to move, remove, or orphan +packages (); and how to handle bug reports +(). +

+The resources discussed in this reference include the mailing lists +and servers (); a discussion of the structure of the +Debian archive (); explanation of the different +servers which accept package uploads (); and a +discussion of resources which an help maintainers with the quality of +their packages (). +

+It should be clear that this reference does not discuss the details of +the Debian package or how to generate Debian packages; that is +discussed in the . Nor is this reference intended to +give details on standards for how Debian software must behave, which +is documented in the . + + + Applying to Become a Maintainer Getting started

So, you've read all the documentation, you understand what everything in the Firstly, subscribe to .

You should subscribe and lurk for a bit before doing any coding, and you should post about your intentions to work on something to avoid duplicated effort.

-If you do not have a PGP key yet, generate one. You should probably -read the PGP manual, 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 or high-powered spy techniques. -

-Due to export restrictions by the United States government some Debian -packages, including PGP, have been moved to an ftp site outside of the -United States. You can find the current locations of those packages on -/pub/debian/README.non-US file. -

-If you live in a country where use of cryptography even for -authentication is forbidden then please contact us so we can make -special arrangements. This does not apply in France, where I believe -only encryption and not authentication is forbidden. +Another good list to subscribe to is + for +details. The IRC channel Registering as a Debian developer

Before you decide to work in the Debian Project you have to read the . +Contract">. Registering as a developer means that you agree with and +pledge to uphold the Debian Social Contract; it is very important that +maintainers are in accord with the essential ideas behind Debian +GNU/Linux. Reading the would +also be a good idea. +

+The process of registering as a developer is a process of verifying +your identity and intentions. As the number of people working on +Debian GNU/Linux has grown to over 400 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.

-After that, you should send a message to - -The message should say what you've done and who you are, and should -ask for an account on pgp -kxa in the case of PGP; note that , or -the debian-keyring> package). Please be sure to sign -your request message with your chosen PGP or RSA key. In addition, you -have to mention that you've read the ``Debian Social Contract'' (see -above) and you are expected to know where to find the ``Debian Policy -Manual'' and the ``Debian Packaging Manual.'' -

-Please be sure to include your preferred login name on + +Your name. + +Your preferred login name on Can anyone clarify for me why logins on master +cannot be eight characters? ), as well as the email address +at which you'd prefer to be subscribed to debian.org address). -

-You should also include some mechanism by which we can verify your -real-life identity. For example, any of the following mechanisms -would suffice: - -A PGP or RSA key signed by any well-known signature, such as any -current Debian developer. +A phone number where we can call you. -A scanned (or physically mailed) copy of any formal documents -certifying your identity (such as a birth certificate, national ID -card, U.S. Driver's License, etc.). Please sign the image with your -PGP or RSA key. - - -The following mechanisms are discouraged, but are acceptable if -neither of the first two mechanisms is practical: - +A statement of intention, that is, what package(s) you intend to work +on, which Debian port you will be assisting, or how you intend to +contribute to Debian. -A pointer to a phone listing at which you could be reached (at our -expense). This phone listing should be verifiable independently -through external means such as a national directory-listing service or -other authoritative source. +A statement that you have read and agree to uphold the . -Any other mechanism by which you can establish your real-life identity -with reasonable certainty. +Some mechanism by which we can verify your real-life identity. For +example, any of the following mechanisms would suffice: + + +A PGP key signed by any well-known signature, such as: + + +Any current Debian developer you have met +Any formal certification service (such as Verisign, etc.) that +verifies your identity. A certification that verifies your email +address, and not you identity, is not sufficient. + + +Alternatively, you may identify yourself with a scanned (or physically +mailed) copy of any formal documents certifying your identity (such as +a birth certificate, national ID card, U.S. Driver's License, etc.). +If emailed, please sign the mail with your PGP key. + - -We're sorry about the inconvenience of requiring proof of identity, -but for the moment, such measures are unfortunately the only way we -can ensure the security and reliability of our distribution. +If you do not have a PGP key yet, generate one. Every developer needs +a PGP key in order to sign and verify package uploads. You should read +the PGP manual, 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 or high-powered spy techniques. +

+Your PGP key must be at least 1024 bits long. There is no reason to +use a smaller key, and doing so would be much less secure. Your key +must be signed with at least your own user ID. This prevents user ID +tampering. You can do it by executing `pgp -ks +'. +

+If your PGP key isn't on public PGP key servers such as +pgp.net, please read the documentation available locally +/usr/doc/pgp/keyserv.doc. That document contains +instructions on how to put your key on the public keyservers. +

+Due to export restrictions by the United States government some Debian +packages, including PGP, have been moved to an ftp site outside of the +United States. You can find the current locations of those packages on +/pub/debian/README.non-US file. +

+If you live in a country where use of cryptography even for +authentication is forbidden then please contact us so we can make +special arrangements. This does not apply in France, where I believe +only encryption and not authentication is forbidden. +

+Once you have all your information ready, and your public key is +available on public key servers, send a message to +pgp +-kxa in the case of PGP; note that /pub/debian/doc/debian-keyring.tar.gz, or the +debian-keyring package). Please be sure to sign your +request message with your chosen PGP or RSA key.

Once this information is received and processed, you should be contacted with information about your new Debian maintainer account. -If you don't hear anything within 7-10 days, please re-send your +If you don't hear anything within 7-14 days, please re-send your original message--the new-maintainer volunteers are typically overworked, and mistakes do occasionally happen. - Debian Mentors + Debian Mentors

There is a mailing list called -Every new developer is invited to subscribe to that list (see for details).

Those who prefer one-on-one help (e.g., via private emails) should @@ -162,15 +224,20 @@ also post to that list and an experienced developer will volunteer to help. - Internet Servers + Mailing Lists and Servers Mailing lists

The mailing list server is at , or locally in +/usr/doc/debian/mailing-lists.txt if you have the +doc-debian package installed.

When replying to messages on the mailing list, please do not send a carbon copy (. Cross-posting is discouraged.

+ 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. +

+Online archives of mailing lists are available at . The master server @@ -204,7 +284,7 @@ developers have accounts on this machine.

- The Debian Archive + The Debian Archive Overview

@@ -270,23 +350,26 @@ sections do not fully comply with all our guidelines. As such, they are not officially part of Debian.

For example, every package in the main distribution must fully comply -with the Debian Free Software Guidelines (DFSG) and with all -other policy requirements as described in the Debian Policy -Manual. (The DFSG is our definition of ``free software.'' Check -out the Debian Policy Manual for details.) +with the (DFSG) and with all other +policy requirements as described in the . (The DFSG is our definition of ``free software.'' Check out +the Debian Policy Manual for details.)

The packages which do not apply to the DFSG are placed in the -non-free section. These packages are not considered as part of + -Packages in the contrib section have to apply to the DFSG, but +Packages in the -(The Debian Policy Manual contains a more exact definition of the -three sections. This is just meant to be an introduction.) +(The contains a more exact definition of the three +sections. This is just meant to be an introduction.)

The separation of the three sections at the top-level of the archive is important for all people who want to distribute Debian, either via @@ -363,6 +446,8 @@ are contained in the Stable, unstable, and sometimes frozen

There is always a distribution called dists/stable) and one called -This development cycle is based on the assumption that the `unstable' -distribution becomes `stable' after passing a period of testing as -`frozen'. Unfortunately, even once a distribution is considered -`stable', a few bugs inevitably remain--that's why the stable -distribution is updated every now and then. However, these updates are -tested very carefully and have to be acknowledged individually to -reduce the risk of introducing new bugs. You can find proposed -additions to `stable' in the Note, that development is continued during the ``freeze'' period, -since a new `unstable' distribution is be created when the older -`unstable' is moved to `frozen'. +since a new In summary, there is always a Release code names + + Experimental +

+The +Developers should be very selective in the use of the + +For instance, an experimental encrypted filesystem should probably go +into experimental. A new, beta, version of some software which uses +completely different configuration might go into experimental at the +maintainer's discretion. New software which isn't likely to damage +your system can go into Release code names

Every released Debian distribution has a - Uploading a package + Uploading a package Generating the changes file

@@ -519,22 +630,26 @@ This file is a control file with the following fields:

All of them are mandatory for a Debian upload. See the list of -control fields in the for the contents of these fields.

Notably, the debian/changelog file, should indicate which distribution the -package is intended for. There are three possible values for this -field: `stable', `unstable', or `frozen'; these values can also be -combined. For instance, if you have a crucial security fix release of -a package, and the package has not diverged between the `stable' and -`unstable' distributions, then you might put `stable unstable' in the -debian/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'. Note that setting -the distribution to `stable' means that the pacakge will be placed -into the proposed-updates directory of the Debian archive for -further testing, before it is actually included in `stable'. +package is intended for. There are four possible values for this +field: debian/changelog's +distribution field. Or, if Debian has been frozen, and you want to +get a bug-fix release into proposed-updates directory of the Debian archive for further +testing, before it is actually included in The first time a version is uploaded which corresponds to a particular @@ -558,7 +673,7 @@ reason why this is not the case then the new version of the original source should be uploaded, possibly by using the Checking the package prior to upload + Checking the package prior to upload

Before you upload your package, you should do basic testing on it. Make sure you try the following activities (you'll need to have an @@ -587,7 +702,7 @@ older version of the Debian package around). - Transferring the files to master + Transferring the files to master

To upload a package, you need a personal account on master.debian.org. All maintainers should already @@ -657,7 +772,7 @@ the keys of the developers keyring. 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 @@ -693,7 +808,7 @@ out-of-sync with your control file. In these cases, you should either correct your control file or file a bug against Interim releases + Interim releases

Under certain circumstances it is necessary for someone other than the usual package maintainer to make a release of a package. For example, @@ -742,9 +857,8 @@ set the severity of the bugs fixed in the NMU to "fixed". This ensures that everyone knows that the bug was fixed in an NMU; however the bug is left open until the changes in the NMU are incorporated "officially" into the package by the offical package maintainer. -

-The normal maintainer should do at least one of +The normal maintainer should do at least one of the following: apply the diff, @@ -783,7 +897,7 @@ for a while, send an email to Moving, removing, renaming, and orphaning packages + Moving, Removing, Renaming, and Orphaning Packages

Some archive manipulation operation are not automated in the Debian upload process. This chapter gives guidelines in what to do in these @@ -794,16 +908,21 @@ cases. Sometimes a package will change either it's section or it's subsection. For instance, a package from the `non-free' section might be GPL'd in a later version; in this case you should consider moving -it to `main' or `contrib' (see the for guidelines).

In this case, it is sufficient to edit the package control information -normally and re-upload the package (see the for details). Carefully examine the installation log sent to you when the package is installed into the archive. If for some reason the old location of the package remains, file a bug against Removing packages

If for some reason you want to completely remove a package (say, if it @@ -815,15 +934,19 @@ package should be removed from. If in doubt concerning whether a package is disposable, email Replacing or renaming packages

Sometimes you made a mistake naming the package and you need to rename it. In this case, you need to follow a two-step process. First, set your debian/control file to replace and conflict with the -obsolete name of the package (see the for details). Once you've uploaded +that package, and the package has moved into the archive, file a bug +against Orphaning a package

@@ -836,7 +959,7 @@ email Handling bug reports + Handling Bug Reports Monitoring bugs

@@ -862,6 +985,7 @@ been fixed. Note that when you are neither the bug submitter nor the package maintainer, you are not empowered to actually close the bug (unless you secure permission from the maintainer). + When bugs are closed by new uploads

If you fix a bug in your packages, it is your responsibility as the @@ -876,7 +1000,7 @@ Often, it's sufficient to mail the Lintian reports + Lintian reports

You should periodically get the new Whirlwind Tour of Debian Maintainer Tools +

+This section contains a rough overview of the tools available to +maintainers. These tools are meant to help convenience developers and +free their time for critical tasks. +

+Some people prefer to use high-level package maintenance tools and +some do not. Debian is officially agnostic on this issue, other than +making the attempt to accomodate the reasonable wishes of developers. +Therefore, this section is not meant to stipulate to anyone which +tools they should use or how they should go about with their duties of +maintainership. Nor is it meant to endorse any particular tool to the +exclusion of a competing tool. +

+Most of the descriptions of these packages come from the actual +package descriptions themselves. + + + dpkg-dev +

+dpkg-dev contains the tools (including + + lintian +

+Lintian dissects Debian packages and reports bugs and +policy violations. It contains automated checks for many aspects of +Debian policy as well as some checks for common errors. The use of +lintian has already been discussed in and . + + + debhelper +

+debhelper is a collection of programs that can be used in +debian/rules to automate common tasks related to building +binary Debian packages. Programs are included to install various files +into your package, compress files, fix file permissions, integrate +your package with the Debian menu system. +

+Unlike debmake, debhelper is broken into +several small, granular commands which act in a consistent manner. As +such, it allows a greater granularity of control than +debmake. + + + debmake +

+debmake, a pre-cursor to debhelper, is a +less granular debian/rules assistant. It includes two main +programs: deb-make, which can be used to help a +maintainer convert a regular (non-Debian) source archive into a Debian +source package; and debstd, which incorporates in one big +shot the same sort of automated functions that one finds in +debhelper. + + + cvs-buildpackage +

+cvs-buildpackage provides the capability to inject or +import Debian source packages into a CVS repository, build a Debian +package from the CVS repository, and helps in integrating upstream +changes into the repository. +

+These utilities provide an infrastructure to facilitate the use of CVS +by Debian maintainers. This allows one to keep separate CVS branches +of a package for + dupload +

+dupload is a package and a script to automagically upload +Debian packages to the Debian archive, to log the upload, and to send +mail about the upload of a package. You can configure it for new +upload locations or methods. + -- 2.30.2