tags 459343 + patch
thanks
Heya,
Luk Claes [EMAIL PROTECTED] wrote:
* Please make it more clear that uploads to stable / oldstable do need a
mail to [EMAIL PROTECTED]
* It would also be good to not use stable-proposed-updates if uploading
is mentioned as uploading to stable-proposed-updates doesn't work.
* Mentioning oldstable / oldstable-proposed-updates might also make sense...
* Uploading security updates is mentioned as a deprecated practice, I
think it would be better to link to the section about security uploads
and mention that security issues not considered for a DSA can still be
considered for proposed-updates...
The following patch addresses all of these suggestions. The first item
was done by moving the contact information from the end of the section
to the first paragraph, which seems more sane, as it's the most
important bit. Please review:
Index: pkgs.dbk
===
--- pkgs.dbk(revision 5203)
+++ pkgs.dbk(working copy)
@@ -284,16 +284,25 @@
time.
/para
section id=upload-stable
-titleSpecial case: uploads to the literalstable/literal
distribution/title
+titleSpecial case: uploads to the literalstable/literal and
+literaloldstable/literal distributions/title
para
Uploading to literalstable/literal means that the package will transfered
-to the literalproposed-updates-new/literal-queue for review by the stable
+to the literalproposed-updates-new/literal queue for review by the stable
release managers, and if approved will be installed in
filenamestable-proposed-updates/filename directory of the Debian archive.
From there, it will be included in literalstable/literal with the next
point release.
/para
para
+To ensure that your upload will be accepted, you should discuss the changes
+with the stable release team before you upload. For that, send a mail to
+the email-debian-release; mailing list, including the patch you want to
+apply to the package version currently in literalstable/literal. Always
+be verbose and detailed in your changelog entries for uploads to the
+literalstable/literal distribution.
+/para
+para
Extra care should be taken when uploading to literalstable/literal.
Basically, a package should only be uploaded to literalstable/literal if
one of the following happens:
@@ -321,7 +330,10 @@
used for Debian security advisories are automatically copied to the appropriate
filenameproposed-updates/filename archive when the advisory is released.
See xref linkend=bug-security/ for detailed information on handling
-security problems.
+security problems. If the security teams deems the problem to be too
+benign to be fixed through a literalDSA/literal, the stable release
+managers are usually willing to include your fix nonetheless in a regular
+upload to literalstable/literal.
/para
para
Changing anything else in the package that isn't important is discouraged,
@@ -338,20 +350,10 @@
making those other packages uninstallable, is strongly discouraged.
/para
para
-The Release Team (which can be reached at
-email-debian-release;) will regularly evaluate the uploads to
-literalstable-proposed-updates/literal and decide if your package can be
-included in literalstable/literal. Please be clear (and verbose, if
-necessary) in your changelog entries for uploads to
-literalstable/literal, because otherwise the package won't be considered
-for inclusion.
+Uploads to the literaloldstable/literal distributions are possible as
+long as it hasn't been archived. The same rules as for literalstable
+/literal apply.
/para
-para
-It's best practice to speak with the stable release manager
-emphasisbefore/emphasis uploading to
-literalstable/literal/literalstable-proposed-updates/literal, so
-that the uploaded package fits the needs of the next point release.
-/para
/section
section id=upload-t-p-u
Marc
--
BOFH #199:
the curls in your keyboard cord are losing electricity.
pgpRmmqI5fuXi.pgp
Description: PGP signature
