Rename all GLEPs to .rst

1 files changed, 125 insertions, 0 deletions

diff --git a/glep-0019.rst b/glep-0019.rst
new file mode 100644
index 0000000..27369b4
--- /dev/null
+++ b/glep-0019.rst
@@ -0,0 +1,125 @@
+GLEP: 19
+Title: Gentoo Stable Portage Tree 
+Version: $Revision$
+Last-Modified: $Date$
+Author: Kurt Lieber <klieber@gentoo.org> 
+Status: Withdrawn
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 26-Jan-2004
+Post-History: 29-Jan-2004 2-Nov-2004 7-Dec-2004 10-Oct-2006
+
+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
+environments, mission critical workstations and other such installations.
+
+The proposed solution involves creating a separate tree in Portage that is
+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
+==========
+
+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
+=============
+
+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
+responsible for creating and updating ebuilds as they will be expected to
+integrate the tagging of ebuilds for the stable tree into their normal
+development process, both for the quarterly release cycles as well as
+off-cycle bug and security fixes.
+
+The Gentoo Documentation team will also be affected as they will be
+responsible for updating installation documents to take these new features
+into account.
+
+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
+repository was the appropriate way to accomplish this.  The largest area of
+disagreement surrounded how specific ebuilds should be targeted for inclusion
+in the stable tree.
+
+One suggested solution was a simple branch of the CVS tree and having
+developers work in two separate branches; one for the stable tree and
+another for the traditional tree.  However, it was felt this would prove too
+cumbersome in practice.
+
+Another suggestion was to have a small group of dedicated gentoo-server
+developers responsible for generating the contents of the stable tree, which
+would provide more control and quality assurance over the ebuilds added to the
+stable tree.  While this might prove effective for a small number of ebuilds,
+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.  
+
+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.
+
+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.
+
+
+Copyright
+=========
+
+This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
+Unported License.  To view a copy of this license, visit
+http://creativecommons.org/licenses/by-sa/3.0/.