--- xml/htdocs/proj/en/glep/glep-0019.html 2004/02/02 18:16:31 1.2 +++ xml/htdocs/proj/en/glep/glep-0019.html 2006/10/10 16:56:21 1.5 @@ -8,9 +8,252 @@ --> - + GLEP 19 -- Gentoo Stable Portage Tree - + -
- +
@@ -33,13 +275,13 @@ - + - + - + @@ -47,25 +289,32 @@ - +
Title:Gentoo Stable Portage Tree
Version:1.4
Version:1.8
Last-Modified:2004/01/30 02:41:45
Last-Modified:2006/10/10 16:54:34
Author:Kurt Lieber <klieber at gentoo.org>
Status:Draft
Status:Withdrawn
Type:Standards Track
Created:26-Jan-2004
Post-History:29-Jan-2004
Post-History:29-Jan-2004 2-Nov-2004 7-Dec-2004 10-Oct-2006

-
-

Contents

+ -
-

Abstract

+
+

Status

+

Withdrawn by the author. "If someone wants to take up the torch, more +power to them, but they should probably start clean with a new glep."

+
+
+

Abstract

This GLEP is intended to propose a series of changes to the Portage tree that are necessary to facilitate the use of Gentoo in areas where stability and predictability are of paramount importance, including servers in enterprise @@ -74,15 +323,19 @@ updated far less often than the regular tree. Outside of periodic updates, this tree would only be updated with critical bugfixes and security patches.

-
-

Motivation

+
+

Status

+

Currently recruiting people who would be willing to help with this GLEP.

+
+
+

Motivation

Enterprise users typically value stability and a predictable upgrade path over having the latest packages or features available to them. Historically, Gentoo Linux has been unable to provide such an environment due to the dynamic nature of the Portage tree.

-
-

Specification

+
+

Specification

The Gentoo Infrastructure team will need to provide an additional Portage tree on our rsync mirroring system. This new tree will house the ebuilds associated with the stable tree. It also impacts all Gentoo developers @@ -94,8 +347,8 @@ responsible for updating installation documents to take these new features into account.

-
-

Rationale

+
+

Rationale

A basic outline of various ways of adding a "stable" tree to Portage was discussed in the gentoo managers meeting on 26-Jan-04. Consensus seemed to be reached that such a solution was needed and that branching the gentoo-x86 @@ -113,58 +366,56 @@ it is quite likely that this model would not scale enough to allow for a large number of ebuilds in the stable tree and, over time, the project would become resource constrained and unable to meed future deadlines.

-

The suggestion that seemed to get the most traction was the creation of a new -"stable" keyword which would be added to appropriate ebuilds. The use of -"stable" would signify ebuilds that are ready for production in the stable -tree while "~stable" would be reserved for ebuilds which may be appropriate -for the stable tree, but may require further testing before being deemed -"ready for production". Off-cycle bug fixes and/or security updates may be -examples of ebuilds that require the ~stable tag.

-
-
-

Implementation

-

While a 'stable' keyword was originally proposed, after further review, it was -determined this offered no way to allow arch-specific stable ebuilds. As -such, this GLEP proposes the use of 'stable:<arch>' and '~stable:<arch>' -(stable:x86, stable:ppc, etc.)

-

A new, stable tree will be created by scanning for the 'stable:<arch>' and -'~stable:<arch>' keywords in the ebuilds and pulling those ebuilds and -associated files into a separate branch of CVS. The stable tree should have -the following features:

-
    -
  • Updated quarterly. Frozen during other times except for security/bug fixes
  • -
  • All ebuilds should remain in the tree for a minimum of one year. This -allows users to upgrade as infrequently as once per year without risking -the stable portage tree leaving them behind without an upgrade path.
  • -
-

As mentioned above, the "stable" tree will be updated quarterly, ideally in -unison with the release schedule of the main Gentoo branch. This tree will be -untouched outside of this update schedule except in the following cases:

-
    -
  • Security fixes and patches which result in a GLSA
  • -
  • Bug fixes for bugs ranked as 'maj' or above (may be overridden at the -discretion of the package maintainer.)
  • -
-

In both cases, the maintainer of the package will be responsible for ensuring -these patches are properly committed to the stable tree out of cycle.

+

While the original draft of this GLEP called for the creation of a stable +keyword, we have since discarded that idea in favor of creating a custom +profile, which will be used to track a subset of packages and versions.

-
-

Backwards Compatibility

+
+

Implementation

+

This GLEP will create a new set of cascaded profiles (one per release, not to +exceed two per year) which will contain a subset of packages, including +versions. This profile will "pin" a Gentoo Linux box to a specific set of +packages and will only be updated for security updates and, in rare +circumstances, major bug fixes.

+

Because this profile will be cascaded, the option exists for other developers +to create their own profile, containing a subset of packages not found in the +"main" stable tree and include those as part of the overall stable profile. +These cases will be treated on a one-off basis.

+

The initial version will be x86 only, though other people will be encouraged +to provide separate stable profiles for other arches. It is expected that any +effort to provide a stable tree for any arch or flavor of Gentoo will follow +the basic outline of this GLEP to ensure consistency for our users.

+

In addition to a custom profile, this GLEP will also create a separate rsync +repository, "gentoo-stable-portage", which will be available on all servers in +the rsync.gentoo.org rotation. This repository will be identical to the +main gentoo-portage repository except that the --delete flag will be removed +from the rsync option that populates the tree. This will ensure that users of +the stable profile will not have to worry about ebuilds for their packages +disappearing.

+

Stable profiles will be maintained on an N - 2 basis. That is to say that we +will maintain a stable profile for the most current release, plus the previous +two releases. With the expected release schedule for 2005, this will result +in each profile being supported for approximately 18 months. Future versions +of the stable portage tree may seek to increase the life of these profiles.

+
+
+

Backwards Compatibility

All features proposed here are new additions to existing processes and features. There should be no impact on existing features and functionality.

- - +