r190 - /web/deps/dep10.mdwn

seanius at users.alioth.debian.org seanius at users.alioth.debian.org
Tue May 10 05:45:30 UTC 2011


Author: seanius
Date: Tue May 10 05:45:23 2011
New Revision: 190

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=190
Log:
DEP-10: A little more meat on the bones.

Modified:
    web/deps/dep10.mdwn

Modified: web/deps/dep10.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep10.mdwn?rev=190&op=diff
==============================================================================
--- web/deps/dep10.mdwn (original)
+++ web/deps/dep10.mdwn Tue May 10 05:45:23 2011
@@ -14,7 +14,6 @@
 
 [[!toc levels=2]]
 
-<a name="introduction">
 # Introduction / Problem scope
 
 Currently, as the project nears a new stable release, a freeze is instituted
@@ -31,6 +30,7 @@
 and in some cases prevented from doing non-release targeted activities
 in unstable.
 
+<a name="introduction-probs">
 The reduction of such non-release activity is viewed as problematic in
 this DEP, for some inter-related reasons:
 
@@ -155,7 +155,7 @@
 
 ### Problems with `testing`
 
-(See [Introduction](#introduction))
+(See [Introduction](#introduction-probs))
 
 # Constraints and requirements for any change to the release process
 
@@ -163,31 +163,214 @@
 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. 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).
+ 1. 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. 
+ 1. 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.
+ 1. 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.
+
+# A host of proposals
+
+During the post-squeeze release feedback on debian-devel, there has been a
+number of ideas and suggestions for how the freeze of the release process
+could be minimized, circumvented, or avoided altogether.  Some of the more
+popular and/or controversial alternatives will be discussed and analyzed
+in the following section.
+
+## Branch `testing` at freeze time (a.k.a `frozen v2.0`)
+
+At some point during release preparation, somewhere between the "soft" and
+"hard" freeze points of the current release, the `testing` suite is split
+into two new independant suites.  The first of these suites is used for
+continuing the (frozen) next stable release, while the other continues
+receiving updates via `unstable`.
+
+    Before release         Freeze                 Release
+
+    [unstable/sid]--------------------------------------------------------------
+              \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
+    [testing/R_N]----------[testing/R_N+1]--------------------------------------
+                               \ \ \  \   \    \
+                                [R_N].-.-.-.-.-.-.[stable/R_N].-.-.-.-.-.-.-.-.-
+                                 /    /   /  / / / /         /                /
+                           [R_N p-u].-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
+     
+    [stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-[oldstable/R_N-1]-.-(EOL)
+
+    --------: Normal activity.  Standard rules for uploads and migrations.
+    .-.-.-.-: Release targeted activity.  Freezes and limited uploads. 
+    \ \ \ \ : Package migration activity.  Spacing of marks is a rough
+              indication of frequency.
+
+
+This is very similar to the previous `frozen` release process, though
+with the key difference that at the point the branch-off occurs, the
+suite is in a far better condition due to the additional and continuous
+QA recieved in the `unstable`->`testing` process.
+
+As a consequence, work in `unstable` will quickly diverge from the state
+of the frozen release, which has to immediate consequences:
+ * The release team will rely on using the corresponding `-proposed-updates`
+   pseudo-suite for release-targeted uploads, as undesired transitions/updates
+   in `unstable` will quickly pare off the candidates for direct migration.
+ * The default path (and userbase) of `unstable`->`testing` can no longer
+   be relied upon for the same amount of QA in the release preparation
+   process.
+
+### Benefits
+### Problems
+### Conclusion
+
+## Implement an `unstable-updates`
+
+A new pseudo-suite `unstable-updates` (or some other creative name left
+for a later exercise) is established, which functions in a manner similar
+to the existing `experimental` pseudo-suite.  A key difference from
+`experimental` is that this suite is explicitly expected to feed packages
+to the `unstable` suite, and thus the contents should be subject to the
+same quality standards expected of `unstable` uploads.  Outside of the
+release process, this feeding can be accomplished either by automatic
+`britney` migrations or some form of semi-automatic "gating" process
+requiring ACK's from either the maintainer or the release team.
+
+During freeze, which continues as it does today, the release team disables
+the migrations from `unstable-updates` to `unstable`.  The former, in
+effect, becomes a staging area for updates to the *following* release.
+Post-release, the migration is re-activated, possibly with some additional
+controls allowing the updates to occur in a more orderly fashion if needed.
+
+    Before release         Freeze              Release
+    
+    [unstable-updates]----------------------------------------------------------
+         \ \ \ \ \ \ \ \ \      \            \   \   \ \ \ \ \ \ \ \ \ \ \ \ \ \
+    [unstable/sid]----------.--.--.--.-.-.-.-.----------------------------------
+         \ \ \ \ \ \ \ \ \  \   \    \       \   \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
+    [testing/R_N]----------.-.-.-.-.-.-.-.-.-.-[testing/R_N+1]------------------
+                                          / / \
+                                         / /   [stable/R_N].-.-.-.-.-.-.-.-.-.-.
+                                        / /          /          /           /
+                                   [R_N p-u].-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
+    
+    [stable/R_N-1].-.-.-.-.-.-.-.-.-.-.-.-.-.-[oldstable/R_N-1].-.-.-(EOL)
+    
+    --------: Normal activity.  Standard rules for uploads and migrations.
+    .-.-.-.-: Release targeted activity.  Freezes and limited uploads. 
+    \ \ \ \ : Package migration activity.  Spacing of marks is a rough
+              indication of frequency.
+
+
+### Benefits
+### Problems
+### Conclusion
+
+## Implement "Debian PPA's" and advocate their use
+
+Another alternative which has been brought up at several points in
+discussion is the use of *Personal Package Archives*, a.k.a. *PPA*'s,
+a.k.a. *DSR*'s, as a means to provide packages updates entirely outside
+of the release process.  Individual maintainers, or teams of related
+projects, could establish and host independant and self-contained
+repositories for newer packages.
+
+During a release freeze, these repositories are created on an ad-hoc
+basis to host any updated packages not targeted for release.  Users seeking
+newer software would be directed to add additional APT sources to their
+package manager configuration to enable the updates.
+
+Additionally, PPA's could serve several other purposes apart from avoiding
+the testing freeze.  For example, Outside of the release proucess, they
+can continue to host newer packages than are immediately available in
+unstable, in a manner similar to the existing `experimental` pseudo-suite.
+
+In a manner similar to the `backports.org` services, PPA's could be
+established to serve self-contained sets of backported packages to
+previous stable releases.  For example, newer versions of popular
+desktop software, or entirely desktop environments, could be hosted
+in these self-contained release areas.
+
+PPA's could also be used by maintainers and/or the release team for
+preparation of package transitions outside of `unstable`, providing an
+orderly way to update sets of interdependant packages and reducing
+overall breakage.  This would lead to not only a higher quality experience
+in `testing/unstable`, but also streamline the process for subsequent
+releases, which would experience fewer blockages in work due to
+ongoing transitions.
+
+### Benefits
+### Problems
+### Conclusion
+
+## Implement a `rolling` release
+
+**NOTE**: this section needs to be re-worked.  We're not talking about
+implementing rolling, though there are some key points which do need to
+be discussed in how this implementation would affect and work with rolling.
+The idea of a Debian `rolling` release has been discussed with increased
+amounts of interest and seriousness during and after the `squeeze` release
+cycle.  
+
+While it has been proposed in several shapes and forms, the overarching
+concept is that users should be provided a constantly updating release
+similar to the current `testing` suite, with some key differences:
+
+ * ability to avoid/circumvent blockage from ongoing transitions in
+  `unstable`.
+ * a more official level of support (security, RC bug fixes, etc)
+ * continuous updates, even during release freezes
+
+It's worth note that the motivation/proposal for `rolling` doesn't
+entirely overlap with the motivations behind the DEP.  Certainly both
+proposals involve the ability to have continuous updates during the
+entire release cycle, but beyond that the additional desires regarding
+rolling are orthogonal (or only related in as much as they might place
+constraints on the complementing implementations)
+
+Furthermore, as stated, there have been several *different*
+visions/implementations of `rolling` discussed.  
+
+### `rolling` by way of "alternate entry points"
+
+A new and entirely independant `rolling` suite is established, in parallel
+to testing.  Both suites have a default entry point of the `unstable` suite,
+which feeds both suites through a similar manner.
+
+While packages may migrate into rolling via typical `unstable`
+uploads, there also exist means to directly upload to the suite via a
+`rolling-proposed-updates` or similarly named pseudo-suite.  This
+pseudo suite would be an overlay on top of the standard `rolling` suite,
+allowing for the testing and acceptance of direct fixes without the
+risk of being blocked by any ongoing transitions or otherwise unsatisfiable
+dependency chains.
+
+During a release freeze, 
+as the default entry point for `rolling`, 
+
+`rolling-proposed-updates` could take the
+additional role of accepting new non-release targeted uploads, or
+an additional entry point could be defined to replace the role of
+unstable.
+
+### `rolling` by way of "override hints"
+
+
+
+### Benefits
+### Problems
+### Conclusion
+
 
 
 [1]: http://lists.debian.org/debian-devel/2000/08/msg00906.html




More information about the dep-commits mailing list