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