From f3f30c75d79d811e23b18475d64671e461817743 Mon Sep 17 00:00:00 2001 From: aph Date: Mon, 16 Nov 1998 01:17:18 +0000 Subject: [PATCH] Sec. "Maintainer changes": renamed to "Adopting a package" and moved to Chapter "Moving, Removing, Renaming, Adopting, and Orphaning Packages". Ch. "Non-Maintainer Uploads (NMUs) and Porters": new chapter discussing NMUs and porters; Section "Interim Releases" integrated out of existance of course the obligatory typo, grammar, and spelling corrections git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@719 313b444b-1b9f-4f58-a734-7bb04f332e8d --- developers-reference.sgml | 193 ++++++++++++++++++++++++++++---------- 1 file changed, 145 insertions(+), 48 deletions(-) diff --git a/developers-reference.sgml b/developers-reference.sgml index 59d8288..dc63811 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -7,8 +7,6 @@ @@ -510,8 +508,9 @@ of this writing.

Debian GNU/Linux 1.3 is only available as i386. Debian 2.0 supports i386 and m68k architectures. The next -version of Debian is likely to also support all these, in addition to -alpha, ppc, and sparc architectures. +version of Debian is likely to support i386, m68k, +alpha, and possibly ppc and sparc +architectures. Subsections @@ -519,11 +518,11 @@ version of Debian is likely to also support all these, in addition to The sections Packages @@ -954,7 +953,7 @@ the .changes file must have a valid PGP signature from one of the keys of the developers key-ring. - Announcing package uploads + Announcing package uploads

When a package is uploaded an announcement should be posted to one of the ``debian-changes'' lists. The announcement should give the (source) @@ -1012,20 +1011,36 @@ priorities for packages in the For more information about , +, /usr/doc/debian/bug-log-mailserver.txt, and /usr/doc/debian/bug-maint-info.txt. - Interim releases -

+ + Non-Maintainer Uploads (NMUs) and Porters + +

Under certain circumstances it is necessary for someone other than the -usual package maintainer to make a release of a package. For example, -a porter for another architecture may have to make some small changes -to the source package and does not wish to wait with uploading their -release until the main maintainer has incorporated the patch, or a -serious security problem or bug may have come to light requiring -immediate attention. +usual package maintainer to make a release of a package. This is +called a non-maintainer upload, or NMU. +

+Debian porters, who compile packages for different architectures, do +binary NMUs as part of their normal porting activity. Sometimes, +Debian developers do NMUs in order to fix a serious security problem +or a crippling bug, especially when the package maintainer is unable +to release a fix in a timely fashion. +

+This chapter contains information providing guidelines for when and +how NMUs should be done. + + +Who can do an NMU +

+Only an official Debian developers can do an NMU. + + +When to do an NMU

When a security bug is detected a fixed package should be uploaded as soon as possible. In this case, the Debian Security Managers should @@ -1035,14 +1050,93 @@ the package maintainer cannot provide a fixed package fast enough or if he/she cannot be reached in time, the Security Manager may upload a fixed package.

-When someone other than the usual maintainer releases a package they -should add a new component to the ), NMUs which +fix important or higher severity bugs are encouraged and accepted. +Even during this window, however, you should endeavor to reach the +current maintainer of the package; they might be just about to upload +a fix for the problem.

+Bug fixes to unstable by non-maintainers are also acceptable, but only +as a last resort. Try the following steps first, and if they don't +work, it is ok to do an NMU: +

+ + +Make sure that the package bug is in the Debian BTS. If not, submit a +bug. + +Email the maintainer, and offer to help fix the package bug. Give it a +few days. + +Go ahead and fix the bug, submitting a patch to the right bug in +the Bug Tracking System. + +Wait a couple of weeks for a response. + +Email the maintainer, asking if it is ok to do an NMU. + +Wait a couple of weeks for a response. + +Double check that your patch doesn't have any unexpected side effects. +Build the package and test it as discussed in . + + + When to do an NMU if you are a porter +

+Porters who have to patch the source package in order to get the +package to compile need to follow these steps as well, although their +window of time that they should wait is smaller, since they deal with +a high quantity of packages. +

+Again, the situation will vary depending on the distribution they are +uploading to. Crucial fixes (i.e., changes need to get a source package +to compile) can be uploaded with +However, if you are a porter doing an NMU for `unstable', the above +guidelines for porting should be followed, with one variation. +If you need to alter the source of a package in order to get a +released port of Debian to compile, the bug you submit to the BTS +should be of severity `important' or greater. This ensures that a +single source package can be used to compile every supported Debian +architecture. +

+An acceptable waiting period -- the time between when the bug is +submitted to the BTS and when it is ok to do an NMU -- is ten days +for porters working on the unstable distribution. +

+Try to avoid patches which simply kluge around bugs in the current +version of the compile environment, kernel, or libc. Sometimes +that can't be helped. If you have to kluge around compilers bugs and +the like, make sure you #ifdef your work properly; also, +document your kluge so that people know to remove it once the external +problems have been fixed. +

+Porters may also have an unofficial location where they can put the results +of their work during the waiting period. This helps others running +the port have the benefit of the porter's work, even during the waiting +period. + + +How to do an NMU +

+When someone other than the usual maintainer releases a package they +should add a new minor version number to the foo_1.1-3.dsc. The upstream +version is `1.1' and the Debian revision is `3'. The next NMU would +add a new minor number `.1' to the Debian revision; the new source +control file would be foo_1.1-3.1.dsc. +

+The Debian revision minor number is needed to avoid +`stealing' one of the package maintainer's version numbers, which might +disrupt their work. It also has the benefit of making it visually +clear that a package in the archive was made by an NMU. +

+If there is no dpkg-buildpackage with the + Maintainers other than the usual package maintainer should make as few changes to the package as possible, and they should always send a unified context diff ( If the non-maintainer upload (as known as an ``NMU'') fixes some @@ -1087,30 +1182,7 @@ In addition, the normal maintainer should Maintainer changes -

-Periodically, a listing of packages in need of new maintainers will be -sent to list. This list -is also available at in the Work-Needing and Prospective Packages -document (WNPP), -and at . -If you wish to take over maintenance of any of the packages listed in -the WNPP, or if you can no longer maintain a packages you have, or you -simply want to know if any one is working on a new package, send a -message to -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 -Moving, Removing, Renaming, and Orphaning Packages + Moving, Removing, Renaming, Adopting, 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 @@ -1161,6 +1233,7 @@ against Orphaning a package

If you can no longer maintain a package, then you should set the @@ -1172,6 +1245,30 @@ email Adopting a package +

+Periodically, a listing of packages in need of new maintainers will be +sent to list. This list +is also available at in the Work-Needing and Prospective Packages +document (WNPP), +and at . +If you wish to take over maintenance of any of the packages listed in +the WNPP, or if you can no longer maintain a packages you have, or you +simply want to know if any one is working on a new package, send a +message to +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 +Handling Bug Reports Monitoring bugs -- 2.30.2