From 62dfc977a8d09fda8b2ea98f42ef9dcc8aafae01 Mon Sep 17 00:00:00 2001 From: joy Date: Thu, 18 Oct 2001 00:02:01 +0000 Subject: [PATCH] created a new subsection about uploading to stable, and elaborated about that subject; removed a stray sentence about stable from the paragraph about security uploads (which apply to all distributions equally), and replaced the nonexistent term Security Manager with security officer which I saw used git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1271 313b444b-1b9f-4f58-a734-7bb04f332e8d --- developers-reference.sgml | 56 ++++++++++++++++++++++++++++++--------- 1 file changed, 43 insertions(+), 13 deletions(-) diff --git a/developers-reference.sgml b/developers-reference.sgml index 7f10814..f45f7f6 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -954,14 +954,8 @@ 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). -Also note that setting the distribution to `stable' means -that the package will be placed into the proposed-updates -directory of the Debian archive for further testing before it is actually -included in stable. The Release Team (which can be reached at -&email-debian-release;) will decide if your package can be included in -stable, therefore if your changelog entry is not clear enough, you may -want to explain them why you uploaded your package to stable by sending -them a short explication. +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 @@ -1025,6 +1019,43 @@ original bug fixed and the severity of the bug newly introduced by the fix. + Uploading to stable +

+Uploading to stable means that the package will be placed into the +proposed-updates directory of the Debian archive for further +testing before it is actually included in stable. +

+Extra care should be taken when uploading to stable. Basically, a +package should only be uploaded to stable if one of the following happens: + + a security problem (e.g. a Debian security advisory) + a truely critical functionality problem + the package becomes uninstallable + a released architecture lacks the package + +

+It is discouraged to change anything else in the package that isn't +important, because even trivial fixes can cause bugs later on. Uploading +new upstream versions to fix security problems is deprecated; applying the +specific patch from the new upstream version to the old one ("backporting" +the patch) is the right thing to do in most cases. +

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

+The Release Team (which can be reached at &email-debian-release;) will +regularly evaluate the uploads in proposed-updates and decide if +your package can be included in stable. Please be clear (and +verbose, if necessary) in your changelog entries for uploads to +stable, because otherwise the package won't be considered for +inclusion. + + Checking the package prior to upload

@@ -1341,13 +1372,12 @@ distribution, i.e., stable, unstable, or frozen. Porters have slightly different rules than non-porters, due to their unique circumstances (see ).

-Only critical changes or security bug fixes make it into stable. When -a security bug is detected, a fixed package should be uploaded as soon -as possible. In this case, the Debian Security Managers should get in +When a security bug is detected, a fixed package should be uploaded +as soon as possible. In this case, the Debian security officers get in contact with the package maintainer to make sure a fixed package is uploaded within a reasonable time (less than 48 hours). If 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 +cannot be reached in time, a security officer may upload a fixed package (i.e., do a source NMU).

During the release freeze (see ), NMUs which -- 2.30.2