r188 - /web/deps/dep10.mdwn

[seanius at users.alioth.debian.org]

Author: seanius
Date: Tue May  3 17:47:42 2011
New Revision: 188

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=188
Log:
DEP-10: Discuss some constraints/requirements

Modified:
    web/deps/dep10.mdwn

Modified: web/deps/dep10.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep10.mdwn?rev=188&op=diff
==============================================================================
--- web/deps/dep10.mdwn (original)
+++ web/deps/dep10.mdwn Tue May  3 17:47:42 2011
@@ -142,10 +142,10 @@
  * `testing`: only the "leading edge" of Debian updates.
  * `testing/unstable`: A hybrid solution of the two previous use cases,
     allowing for a reasonable balance between them.
- * `stable`: The latest stable release.
+ * `stabe`: The latest stable release.
  * `stable/testing`: the stable release with perhaps some newer packages
     installed, typically also making use of "APT pins" to prevent unwanted
-    upgrades.  Less common now with the inclusion of backports and volatile
+    upgraes.  Less common now with the inclusion of backports and volatile
 	as official Debian services.
 
 ### Benefits with `testing`
@@ -158,4 +158,37 @@
 
 (See [Introduction](#introduction))
 
+# Constraints and requirements for any change to the release process
+
+Based on feedback on the `debian-devel` mailing list, this proposal
+makes a number of assumptions about constraints and requirements for
+any alteration of the current release process.
+
+## Any irreconcilable conflict should side towards release preparation
+
+ * activity which can not be done in parellel must only be done for
+   release preparation.
+ * any proposal must be no less safe than the current system with
+   regards to human error (uploads to wrong suite, etc, un-unannounced
+   transitions, etc).
+
+## Debian stable releases need sufficient test coverage by users
+
+ * a testing (or testing-like) quarantine is needed for QA purposes
+ * sufficient users should be using this quarantine to give good coverage. 
+
+## Any parallel work should interfere minimally with release preparations
+
+ * newer software should not prevent an upload path to the release.
+ * library transitions and similar should not cause unreasonable overhead.
+ * it must still be possible to remove packages from the release.
+
+## The upgrade path and archive state must be consistant and reconcilable
+
+ * packages updated outside of the release should always have higher versions
+   than in the release, even if both were updated.
+ * If the suite contents are to change post-release, the proposal must
+   account for renamed/duplicate/removed packagets.
+
+
 [1]: http://lists.debian.org/debian-devel/2000/08/msg00906.html