+When you know how you want to contribute to the Debian Project, you
+should get in contact with existing Debian maintainers who are working
+on similar tasks. That way, you can learn from experienced developers.
+For example, if you are interested in packaging existing software for
+Debian you should try to get a sponsor. A sponsor will work together
+with you on your package and upload it to the Debian archive once he
+is happy with the packaging work you have done. You can find a sponsor
+by mailing the &email-debian-mentors; mailing list, describing your
+package and yourself and asking for a sponsor (see
+for more information on sponsoring). On the other hand, if you are
+interested in porting Debian to alternative architectures or kernels
+you can subscribe to port specific mailing lists and ask there how to
+get started. Finally, if you are interested in documentation or
+Quality Assurance (QA) work you can join maintainers already working on
+these tasks and submit patches and improvements.
+
Before you decide to register with the Debian Project, you will need
-to read the
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 &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.
-
-Registration requires that the following information be sent in
-appropriate steps described at
+Before you actually register you should have shown that you can do
+competent work and will be a good contributor. You can show this by
+submitting patches through the Bug Tracking System or having a package
+sponsored by an existing maintainer for a while. Also, we expect that
+contributors are interested in the whole project and not just in
+maintaining their own packages. If you can help other maintainers by
+providing further information on a bug or even a patch, then do so!
+
+Registration requires that you are familiar with Debian's philosophy
+and technical documentation. Furthermore, you need a GPG key which
+has been signed by an existing Debian maintainer. If your GPG key
+is not signed yet, you should try to meet a Debian maintainer in
+person to get your key signed. There's a
If you do not have an OpenPGP key yet, generate one. Every developer
needs a OpenPGP key in order to sign and verify package uploads. You
@@ -200,13 +197,6 @@ much less secure. Your key must be signed with at least your own user
ID; this prevents user ID tampering.
-Also remember that one of the names on your key must match the email
-address you list as the official maintainer for your packages. For
-instance, I set the maintainer of the
-
If your public key isn't on public key servers such as &pgp-keyserv;,
please read the documentation available locally in &file-keyservs;.
That document contains instructions on how to put your key on the
@@ -227,28 +217,28 @@ cryptography qua cryptography in any manner. 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.
-Once you have all your information ready, and your public key is
-available on public key servers, send a message to
-&email-new-maintainer; to register as an offical Debian developer so
-that you will be able to upload your packages. This message must
-contain your name and your valid e-mail address. All the information
-discussed above is required after your Application Manager is
-assigned. Application Manager is your agent in the registration
-process, and you can always ask him about the status of your
-application. You can check the
+When you have found an advocate, have your GPG key signed and have
+already contributed to Debian for a while, you're ready to apply.
+You can simply register on our
For more details, please consult
-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 a month, please send a followup
-message asking if your original application was received. Do
-not re-send your original application, that will just confuse
-the New Maintainer Group. Please be patient, especially near release
-points; mistakes do occasionally happen, and people do sometimes run
-out of volunteer time.
+Maintainer's Corner"> at the Debian web site. Make sure that you
+are familiar with the necessary steps of the New Maintainer process
+before actually applying. If you are prepared well, you can save
+a lot of timer later on.
You have to keep the information available there up to date.
@@ -309,10 +299,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 +358,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
@@ -784,41 +794,42 @@ shows up for a couple of months from time to time.
The experimental distribution is a specialty distribution.
It is not a full distribution in the same sense as `stable' and
`unstable' are. Instead, it is meant to be a temporary staging area
for highly experimental software where there's a good chance that the
-software could break your system. Users who download and install
+software could break your system, or software that's just too unstable
+even for the unstable distribution (but there is a reason to
+package it nevertheless). Users who download and install
packages from experimental are expected to have been duly
warned. In short, all bets are off for the experimental
distribution.
-Developers should be very selective in the use of the
-experimental distribution. Even if a package is highly
-unstable, it could still go into unstable; just state a
-few warnings in the description. However, if there is a chance that
-the software could do grave damage to a system, it might be better to
-put it into experimental.
-
+If there is a chance that the software could do grave damage to a system,
+it is likely to be better to put it into experimental.
For instance, an experimental compressed file system 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
-unstable. If you are working on an incompatible or complex
-upgrade situation, you can also use experimental as a staging
-area, so that testers can get early access.
-
-However, using experimental as a personal staging area is not
-always the best idea, especially with transient packages. For
-example, you cannot delete packages which have been uploaded to
-experimental on your own; that must be done by the Debian
-archive maintainers. An alternative is to use your personal web space
-on klecker.debian.org, a.k.a. people.debian.org.
+into experimental.
+
+Whenever there is a new upstream version of a package that introduces new
+features but breaks a lot of old ones, it should either not be uploaded, or
+be uploaded to experimental. A new, beta, version of some software
+which uses completely different configuration can go into
+experimental, at the maintainer's discretion. If you are working
+on an incompatible or complex upgrade situation, you can also use
+experimental as a staging area, so that testers can get early
+access.
+
+Some experimental software can still go into unstable, with a few
+warnings in the description, but that isn't recommended because packages
+from unstable are expected to propagate to testing and
+thus to stable.
+
+New software which isn't likely to damage your system can go directly into
+unstable.
+
+An alternative to experimental is to use your personal web space
+on people.debian.org (klecker.debian.org).
Please include a Closes: bug#nnnnn entry on the
@@ -914,11 +925,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
@@ -933,29 +971,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
@@ -978,6 +997,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
@@ -1057,36 +1102,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
@@ -1238,12 +1254,6 @@ package is released with Distribution: set to `unstable',
`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 will go to both of the above
-mailing lists.
-
The
Sponsoring a package means uploading a package for a maintainer who is not
able to do it on their own, a new maintainer applicant. Sponsoring a package
-
-
-
-
-
+
-
-
-
+