Uploading to stable means that the package will transferred to the proposed-updates-new queue for review by the stable release managers, and if approved will be installed in stable-proposed-updates directory of the Debian archive. From there, it will be included in stable with the next point release.

To ensure that your upload will be accepted, you should discuss the changes with the stable release team before you upload. For that, file a bug against the release.debian.org pseudo-package using reportbug, including the patch you want to apply to the package version currently in stable. Always be verbose and detailed in your changelog entries for uploads to the stable distribution.

Extra care should be taken when uploading to stable. Basically, a package should only be uploaded to stable if one of the following happens:

In the past, uploads to stable were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories are automatically copied to the appropriate proposed-updates archive when the advisory is released. See Section 5.8.5, “Handling security-related bugs” for detailed information on handling security problems. If the security teams deems the problem to be too benign to be fixed through a DSA, the stable release managers are usually willing to include your fix nonetheless in a regular upload to stable.

Changing anything else in the package that isn't important is discouraged, because even trivial fixes can cause bugs later on.

Packages uploaded to stable need to be compiled on systems running stable, so that their dependencies are limited to the libraries (and other packages) available in stable; for example, a package uploaded to stable that depends on a library package that only exists in unstable will be rejected. Making changes to dependencies of other packages (by messing with Provides or shlibs files), possibly making those other packages uninstallable, is strongly discouraged.

Uploads to the oldstable distributions are possible as long as it hasn't been archived. The same rules as for stable apply.

Please see the information in the testing section for details.

To upload a package, you should upload the files (including the signed changes and dsc-file) with anonymous ftp to ftp.upload.debian.org in the directory /pub/UploadQueue/. To get the files processed there, they need to be signed with a key in the Debian Developers keyring or the Debian Maintainers keyring (see http://wiki.debian.org/DebianMaintainer).

Please note that you should transfer the changes file last. Otherwise, your upload may be rejected because the archive maintenance software will parse the changes file and see that not all files have been uploaded.

You may also find the Debian packages dupload or dput useful when uploading packages.These handy programs help automate the process of uploading packages into Debian.

For removing packages, please see ftp://ftp.upload.debian.org/pub/UploadQueue/README and the Debian package dcut.

It is sometimes useful to upload a package immediately, but to want this package to arrive in the archive only a few days later. For example, when preparing a Non-Maintainer Upload, you might want to give the maintainer a few days to react.

An upload to the delayed directory keeps the package in the deferred uploads queue. When the specified waiting time is over, the package is moved into the regular incoming directory for processing. This is done through automatic uploading to ftp.upload.debian.org in upload-directory DELAYED/X-day (X between 0 and 15). 0-day is uploaded multiple times per day to ftp.upload.debian.org.

With dput, you can use the --delayed DELAY parameter to put the package into one of the queues.

Do NOT upload a package to the security upload queue (oldstable-security, stable-security, etc.) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload. For details, please see Section 5.8.5, “Handling security-related bugs”.

There is an alternative upload queue in Europe at ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. It operates in the same way as ftp.upload.debian.org, but should be faster for European developers.

Packages can also be uploaded via ssh to ssh.upload.debian.org; files should be put /srv/upload.debian.org/UploadQueue. This queue does not support delayed uploads.

The Debian archive maintainers are responsible for handling package uploads. For the most part, uploads are automatically handled on a daily basis by the archive maintenance tools, dak process-upload. Specifically, updates to existing packages to the unstable distribution are handled automatically. In other cases, notably new packages, placing the uploaded package into the distribution is handled manually. When uploads are handled manually, the change to the archive may take some time to occur. Please be patient.

In any case, you will receive an email notification indicating that the package has been added to the archive, which also indicates which bugs will be closed by the upload. Please examine this notification carefully, checking if any bugs you meant to close didn't get triggered.

The installation notification also includes information on what section the package was inserted into. If there is a disparity, you will receive a separate email notifying you of that. Read on below.

Note that if you upload via queues, the queue daemon software will also send you a notification by email.

If you want to be a good maintainer, you should periodically check the Debian bug tracking system (BTS) for your packages. The BTS contains all the open bugs against your packages. You can check them by browsing this page: http://bugs.debian.org/yourlogin@debian.org.

Maintainers interact with the BTS via email addresses at bugs.debian.org. Documentation on available commands can be found at http://www.debian.org/Bugs/, or, if you have installed the doc-debian package, you can look at the local files /usr/share/doc/debian/bug-*.

Some find it useful to get periodic reports on open bugs. You can add a cron job such as the following if you want to get a weekly email outlining all the open bugs against your packages:

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

Replace address with your official Debian maintainer address.

When responding to bugs, make sure that any discussion you have about bugs is sent both to the original submitter of the bug, and to the bug itself (e.g., <123@bugs.debian.org>). If you're writing a new mail and you don't remember the submitter email address, you can use the <123-submitter@bugs.debian.org> email to contact the submitter and to record your mail within the bug log (that means you don't need to send a copy of the mail to <123@bugs.debian.org>).

If you get a bug which mentions FTBFS, this means Fails to build from source. Porters frequently use this acronym.

Once you've dealt with a bug report (e.g. fixed it), mark it as done (close it) by sending an explanation message to <123-done@bugs.debian.org>. If you're fixing a bug by changing and uploading the package, you can automate bug closing as described in Section 5.8.4, “When bugs are closed by new uploads”.

You should never close bugs via the bug server close command sent to <control@bugs.debian.org>. If you do so, the original submitter will not receive any information about why the bug was closed.

As a package maintainer, you will often find bugs in other packages or have bugs reported against your packages which are actually bugs in other packages. The bug tracking system's features are described in the BTS documentation for Debian developers. Operations such as reassigning, merging, and tagging bug reports are described in the BTS control server documentation. This section contains some guidelines for managing your own bugs, based on the collective Debian developer experience.

Filing bugs for problems that you find in other packages is one of the civic obligations of maintainership, see Section 7.1, “Bug reporting” for details. However, handling the bugs in your own packages is even more important.

Here's a list of steps that you may follow to handle a bug report:

As bugs and problems are fixed in your packages, it is your responsibility as the package maintainer to close these bugs. However, you should not close a bug until the package which fixes the bug has been accepted into the Debian archive. Therefore, once you get notification that your updated package has been installed into the archive, you can and should close the bug in the BTS. Also, the bug should be closed with the correct version.

However, it's possible to avoid having to manually close bugs after the upload — just list the fixed bugs in your debian/changelog file, following a certain syntax, and the archive maintenance software will close the bugs for you. For example:

acme-cannon (3.1415) unstable; urgency=low

  * Frobbed with options (closes: Bug#98339)
  * Added safety to prevent operator dismemberment, closes: bug#98765,
    bug#98713, #98714.
  * Added man page. Closes: #98725.

Technically speaking, the following Perl regular expression describes how bug closing changelogs are identified:

  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig

We prefer the closes: #XXX syntax, as it is the most concise entry and the easiest to integrate with the text of the changelog. Unless specified different by the -v-switch to dpkg-buildpackage, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the .changes file are closed).

Historically, uploads identified as non-maintainer upload (NMU) were tagged fixed instead of being closed, but that practice was ceased with the advent of version-tracking. The same applied to the tag fixed-in-experimental.

If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused. To reopen wrongly closed bugs, send a reopen XXX command to the bug tracking system's control address, <control@bugs.debian.org>. To close any remaining bugs that were fixed by your upload, email the .changes file to <XXX-done@bugs.debian.org>, where XXX is the bug number, and put Version: YYY and an empty line as the first two lines of the body of the email, where YYY is the first version where the bug has been fixed.

Bear in mind that it is not obligatory to close bugs using the changelog as described above. If you simply want to close bugs that don't have anything to do with an upload you made, do it by emailing an explanation to <XXX-done@bugs.debian.org>. Do not close bugs in the changelog entry of a version if the changes in that version of the package don't have any bearing on the bug.

For general information on how to write your changelog entries, see Section 6.3, “Best practices for debian/changelog”.

Due to their sensitive nature, security-related bugs must be handled carefully. The Debian Security Team exists to coordinate this activity, keeping track of outstanding security problems, helping maintainers with security problems or fixing them themselves, sending security advisories, and maintaining security.debian.org.

When you become aware of a security-related bug in a Debian package, whether or not you are the maintainer, collect pertinent information about the problem, and promptly contact the security team, preferably by filing a ticket in their Request Tracker. See http://wiki.debian.org/rt.debian.org#Security_Team. Alternatively you may email <team@security.debian.org>. DO NOT UPLOAD any packages for stable without contacting the team. Useful information includes, for example:

As the maintainer of the package, you have the responsibility to maintain it, even in the stable release. You are in the best position to evaluate patches and test updated packages, so please see the sections below on how to prepare packages for the Security Team to handle.

Sometimes a package will change its section. For instance, a package from the non-free section might be GPL'd in a later version, in which case the package should be moved to `main' or `contrib'.^[3]

If you need to change the section for one of your packages, change the package control information to place the package in the desired section, and re-upload the package (see the Debian Policy Manual for details). You must ensure that you include the .orig.tar.{gz,bz2,xz} in your upload (even if you are not uploading a new upstream version), or it will not appear in the new section together with the rest of the package. If your new section is valid, it will be moved automatically. If it does not, then contact the ftpmasters in order to understand what happened.

If, on the other hand, you need to change the subsection of one of your packages (e.g., ``devel'', ``admin''), the procedure is slightly different. Correct the subsection as found in the control file of the package, and re-upload that. Also, you'll need to get the override file updated, as described in Section 5.7, “Specifying the package section, subsection and priority”.

If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against ftp.debian.org asking that the package be removed; as all bugs, this bug should normally have normal severity. The bug title should be in the form RM: package [architecture list] -- reason, where package is the package to be removed and reason is a short summary of the reason for the removal request. [architecture list] is optional and only needed if the removal request only applies to some architectures, not all. Note that the reportbug will create a title conforming to these rules when you use it to report a bug against the ftp.debian.org pseudo-package.

If you want to remove a package you maintain, you should note this in the bug title by prepending ROM (Request Of Maintainer). There are several other standard acronyms used in the reasoning for a package removal, see http://ftp-master.debian.org/removals.html for a complete list. That page also provides a convenient overview of pending removal requests.

Note that removals can only be done for the unstable, experimental and stable distribution. Packages are not removed from testing directly. Rather, they will be removed automatically after the package has been removed from unstable and no package in testing depends on it.

There is one exception when an explicit removal request is not necessary: If a (source or binary) package is no longer built from source, it will be removed semi-automatically. For a binary-package, this means if there is no longer any source package producing this binary package; if the binary package is just no longer produced on some architectures, a removal request is still necessary. For a source-package, this means that all binary packages it refers to have been taken over by another source package.

In your removal request, you have to detail the reasons justifying the request. This is to avoid unwanted removals and to keep a trace of why a package has been removed. For example, you can provide the name of the package that supersedes the one to be removed.

Usually you only ask for the removal of a package maintained by yourself. If you want to remove another package, you have to get the approval of its maintainer. Should the package be orphaned and thus have no maintainer, you should first discuss the removal request on <debian-qa@lists.debian.org>. If there is a consensus that the package should be removed, you should reassign and retitle the O: bug filed against the wnpp package instead of filing a new bug as removal request.

Further information relating to these and other package removal related topics may be found at http://wiki.debian.org/ftpmaster_Removals and http://qa.debian.org/howto-remove.html.

If in doubt concerning whether a package is disposable, email <debian-devel@lists.debian.org> asking for opinions. Also of interest is the apt-cache program from the apt package. When invoked as apt-cache showpkg package, the program will show details for package, including reverse depends. Other useful programs include apt-cache rdepends, apt-rdepends, build-rdeps (in the devscripts package) and grep-dctrl. Removal of orphaned packages is discussed on <debian-qa@lists.debian.org>.

Once the package has been removed, the package's bugs should be handled. They should either be reassigned to another package in the case where the actual code has evolved into another package (e.g. libfoo12 was removed because libfoo13 supersedes it) or closed if the software is simply no longer part of Debian. When closing the bugs, to avoid marking the bugs as fixed in versions of the packages in previous Debian releases, they should be marked as fixed in the version <most-recent-version-ever-in-Debian>+rm.

When the upstream maintainers for one of your packages chose to rename their software (or you made a mistake naming your package), you should follow a two-step process to rename it. In the first step, change the debian/control file to reflect the new name and to replace, provide and conflict with the obsolete package name (see the Debian Policy Manual for details). Please note that you should only add a Provides relation if all packages depending on the obsolete package name continue to work after the renaming. Once you've uploaded the package and the package has moved into the archive, file a bug against ftp.debian.org asking to remove the package with the obsolete name (see Section 5.9.2, “Removing packages”). Do not forget to properly reassign the package's bugs at the same time.

At other times, you may make a mistake in constructing your package and wish to replace it. The only way to do this is to increase the version number and upload a new version. The old version will be expired in the usual manner. Note that this applies to each part of your package, including the sources: if you wish to replace the upstream source tarball of your package, you will need to upload it with a different version. An easy possibility is to replace foo_1.00.orig.tar.gz with foo_1.00+0.orig.tar.gz or foo_1.00.orig.tar.bz2. This restriction gives each file on the ftp site a unique name, which helps to ensure consistency across the mirror network.

If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to Debian QA Group <packages@qa.debian.org> and submit a bug report against the pseudo package wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug should be set to normal; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to <debian-devel@lists.debian.org> 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).

If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against wnpp and title it RFA: package -- short description. RFA stands for Request For Adoption.

More information is on the WNPP web pages.

A list of packages in need of a new maintainer is available in the Work-Needing and Prospective Packages list (WNPP). If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned page for information and procedures.

It is not OK to simply take over a package that you feel is neglected — that would be package hijacking. You can, of course, contact the current maintainer and ask them if you may take over the package. If you have reason to believe a maintainer has gone AWOL (absent without leave), see Section 7.4, “Dealing with inactive and/or unreachable maintainers”.

Generally, you may not take over the package without the assent of the current maintainer. Even if they ignore you, that is still not grounds to take over a package. Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the technical committee web page for more information).

If you take over an old package, you probably want to be listed as the package's official maintainer in the bug system. This will happen automatically once you upload a new version with an updated Maintainer field, although it can take a few hours after the upload is done. If you do not expect to upload a new version for a while, you can use Section 4.10, “The Package Tracking System” to get the bug reports. However, make sure that the old maintainer has no problem with the fact that they will continue to receive the bugs during that time.

Porters have a difficult and unique task, since they are required to deal with a large volume of packages. Ideally, every source package should build right out of the box. Unfortunately, this is often not the case. This section contains a checklist of ``gotchas'' often committed by Debian maintainers — common problems which often stymie porters, and make their jobs unnecessarily difficult.

The first and most important thing is to respond quickly to bug or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.

By far, most of the problems encountered by porters are caused by packaging bugs in the source packages. Here is a checklist of things you should check or be aware of.

If the package builds out of the box for the architecture to be ported to, you are in luck and your job is easy. This section applies to that case; it describes how to build and upload your binary package so that it is properly installed into the archive. If you do have to patch the package in order to get it to compile for the other architecture, you are actually doing a source NMU, so consult Section 5.11.1, “When and how to do an NMU” instead.

For a porter upload, no changes are being made to the source. You do not need to touch any of the files in the source package. This includes debian/changelog.

The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B -mporter-email. Of course, set porter-email to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the binary-arch target in debian/rules.

If you are working on a Debian machine for your porting efforts and you need to sign your upload locally for its acceptance in the archive, you can run debsign on your .changes file to have it signed conveniently, or use the remote signing mode of dpkg-sig.

There is infrastructure and several tools to help automate package porting. This section contains a brief overview of this automation and porting to these tools; see the package documentation or references for full information.

Some packages still have issues with building and/or working on some of the architectures supported by Debian, and cannot be ported at all, or not within a reasonable amount of time. An example is a package that is SVGA-specific (only available for i386 and amd64), or uses other hardware-specific features not supported on all architectures.

In order to prevent broken packages from being uploaded to the archive, and wasting buildd time, you need to do a few things:

Please note that it is insufficient to only add your package to Packages-arch-specific without making it fail to build on unsupported architectures: A porter or any other person trying to build your package might accidently upload it without noticing it doesn't work. If in the past some binary packages were uploaded on unsupported architectures, request their removal by filing a bug against ftp.debian.org.

By default packages from the non-free section are not built by the autobuilder network (mostly because the license of the packages could disapprove). To enable a package to be build you need to perform the following steps:

Before doing an NMU, consider the following questions:

When doing an NMU, you must first make sure that your intention to NMU is clear. Then, you must send a patch with the differences between the current package and your proposed NMU to the BTS. The nmudiff script in the devscripts package might be helpful.

While preparing the patch, you should better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of integrating your changes into the normal package workflow and thus increases the chances that integration will happen. A good place where to look for for possible package-specific practices is debian/README.source.

Unless you have an excellent reason not to do so, you must then give some time to the maintainer to react (for example, by uploading to the DELAYED queue). Here are some recommended values to use for delays:

Those delays are only examples. In some cases, such as uploads fixing security issues, or fixes for trivial bugs that blocking a transition, it is desirable that the fixed package reaches unstable sooner.

Sometimes, release managers decide to allow NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list themselves in the Low Threshold NMU list, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available in the BTS before, or if you know that the maintainer is generally active.

After you upload an NMU, you are responsible for the possible problems that you might have introduced. You must keep an eye on the package (subscribing to the package on the PTS is a good way to achieve this).

This is not a license to perform NMUs thoughtlessly. If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a timely manner, or if you ignore the recommendations of this document, your upload might be a cause of conflict with the maintainer. You should always be prepared to defend the wisdom of any NMU you perform on its own merits.

Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry must explicitely mention that this upload is an NMU, e.g.:

  * Non-maintainer upload.

The way to version NMUs differs for native and non-native packages.

If the package is a native package (without a Debian revision in the version number), the version must be the version of the last maintainer upload, plus +nmuX, where X is a counter starting at 1. If the last upload was also an NMU, the counter should be increased. For example, if the current version is 1.5, then an NMU would get version 1.5+nmu1.

If the package is not a native package, you should add a minor version number to the Debian revision part of the version number (the portion after the last hyphen). This extra number must start at 1. For example, if the current version is 1.5-2, then an NMU would get version 1.5-2.1. If a new upstream version is packaged in the NMU, the Debian revision is set to 0, for example 1.6-0.1.

In both cases, if the last upload was also an NMU, the counter should be increased. For example, if the current version is 1.5+nmu3 (a native package which has already been NMUed), the NMU would get version 1.5+nmu4.

A special versioning scheme is needed to avoid disrupting the maintainer's work, since using an integer for the Debian revision will potentially conflict with a maintainer upload already in preparation at the time of an NMU, or even one sitting in the ftp NEW queue. It also has the benefit of making it visually clear that a package in the archive was not made by the official maintainer.

If you upload a package to testing or stable, you sometimes need to "fork" the version number tree. This is the case for security uploads, for example. For this, a version of the form +debXYuZ should be used, where X and Y are the major and minor release numbers, and Z is a counter starting at 1. When the release number is not yet known (often the case for testing, at the beginning of release cycles), the lowest release number higher than the last stable release number must be used. For example, while Lenny (Debian 5.0) is stable, a security NMU to stable for a package at version 1.5-3 would have version 1.5-3+deb50u1, whereas a security NMU to Squeeze would get version 1.5-3+deb60u1. After the release of Squeeze, security uploads to the testing distribution will be versioned +deb61uZ, until it is known whether that release will be Debian 6.1 or Debian 7.0 (if that becomes the case, uploads will be versioned as +deb70uZ).

Having to wait for a response after you request permission to NMU is inefficient, because it costs the NMUer a context switch to come back to the issue. The DELAYED queue (see Section 5.6.2, “Delayed uploads”) allows the developer doing the NMU to perform all the necessary tasks at the same time. For instance, instead of telling the maintainer that you will upload the updated package in 7 days, you should upload the package to DELAYED/7 and tell the maintainer that he has 7 days to react. During this time, the maintainer can ask you to delay the upload some more, or cancel your upload.

The DELAYED queue should not be used to put additional pressure on the maintainer. In particular, it's important that you are available to cancel or delay the upload before the delay expires since the maintainer cannot cancel the upload himself.

If you make an NMU to DELAYED and the maintainer updates his package before the delay expires, your upload will be rejected because a newer version is already available in the archive. Ideally, the maintainer will take care to include your proposed changes (or at least a solution for the problems they address) in that upload.

When someone NMUs your package, this means they want to help you to keep it in good shape. This gives users fixed packages faster. You can consider asking the NMUer to become a co-maintainer of the package. Receiving an NMU on a package is not a bad thing; it just means that the package is interesting enough for other people to work on it.

To acknowledge an NMU, include its changes and changelog entry in your next maintainer upload. If you do not acknowledge the NMU by including the NMU changelog entry in your changelog, the bugs will remain closed in the BTS but will be listed as affecting your maintainer version of the package.

The full name of an NMU is source NMU. There is also another type, namely the binary-only NMU, or binNMU. A binNMU is also a package upload by someone other than the package's maintainer. However, it is a binary-only upload.

When a library (or other dependency) is updated, the packages using it may need to be rebuilt. Since no changes to the source are needed, the same source package is used.

BinNMUs are usually triggered on the buildds by wanna-build. An entry is added to debian/changelog, explaining why the upload was needed and increasing the version number as described in Section 5.10.2.1, “Recompilation or binary-only NMU”. This entry should not be included in the next upload.

Buildds upload packages for their architecture to the archive as binary-only uploads. Strictly speaking, these are binNMUs. However, they are not normally called NMU, and they don't add an entry to debian/changelog.

NMUs are uploads of packages by somebody else than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.

QA uploads are very much like normal maintainer uploads: they may fix anything, even minor issues; the version numbering is normal, and there is no need to use a delayed upload. The difference is that you are not listed as the Maintainer or Uploader for the package. Also, the changelog entry of a QA upload has a special first line:

 * QA upload.

If you want to do an NMU, and it seems that the maintainer is not active, it is wise to check if the package is orphaned (this information is displayed on the package's Package Tracking System page). When doing the first QA upload to an orphaned package, the maintainer should be set to Debian QA Group <packages@qa.debian.org>. Orphaned packages which did not yet have a QA upload still have their old maintainer set. There is a list of them at http://qa.debian.org/orphaned.html.

Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package, you can just set yourself as maintainer and upload the new version (see Section 5.9.5, “Adopting a package”).

Sometimes you are fixing and/or updating a package because you are member of a packaging team (which uses a mailing list as Maintainer or Uploader, see Section 5.12, “Collaborative maintenance”) but you don't want to add yourself to Uploaders because you do not plan to contribute regularly to this specific package. If it conforms with your team's policy, you can perform a normal upload without being listed directly as Maintainer or Uploader. In that case, you should start your changelog entry with the following line:

 * Team upload.

Packages are usually installed into the testing distribution after they have undergone some degree of testing in unstable.

They must be in sync on all architectures and mustn't have dependencies that make them uninstallable; they also have to have generally no known release-critical bugs at the time they're installed into testing. This way, testing should always be close to being a release candidate. Please see below for details.

The scripts that update the testing distribution are run twice each day, right after the installation of the updated packages; these scripts are called britney. They generate the Packages files for the testing distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages.

The inclusion of a package from unstable is conditional on the following:

To find out whether a package is progressing into testing or not, see the testing script output on the web page of the testing distribution, or use the program grep-excuses which is in the devscripts package. This utility can easily be used in a crontab(5) to keep yourself informed of the progression of your packages into testing.

The update_excuses file does not always give the precise reason why the package is refused; you may have to find it on your own by looking for what would break with the inclusion of the package. The testing web page gives some more information about the usual problems which may be causing such troubles.

Sometimes, some packages never enter testing because the set of interrelationship is too complicated and cannot be sorted out by the scripts. See below for details.

Some further dependency analysis is shown on http://release.debian.org/migration/ — but be warned, this page also shows build dependencies which are not considered by britney.

The testing distribution is fed with packages from unstable according to the rules explained above. However, in some cases, it is necessary to upload packages built only for testing. For that, you may want to upload to testing-proposed-updates.

Keep in mind that packages uploaded there are not automatically processed, they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the release managers' eyes, you should read the instructions that they regularly give on <debian-devel-announce@lists.debian.org>.

You should not upload to testing-proposed-updates when you can update your packages through unstable. If you can't (for example because you have a newer development version in unstable), you may use this facility, but it is recommended that you ask for authorization from the release manager first. Even if a package is frozen, updates through unstable are possible, if the upload via unstable does not pull in any new dependencies.

Version numbers are usually selected by adding the codename of the testing distribution and a running number, like 1.2squeeze1 for the first upload through testing-proposed-updates of package version 1.2.

Please make sure you didn't miss any of these items in your upload: