en/glep/glep-0019.txt

GLEP: 19
Title: Gentoo Stable Portage Tree 
Version: $Revision: 1.7 $
Last-Modified: $Date: 2004/11/02 15:38:58 $
Author: Kurt Lieber <klieber@gentoo.org> 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2004
Post-History: 29-Jan-2004 2-Nov-2004 7-Dec-2004


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.

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
=============

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 document is licensed under the Creative Commons - Attribution / Share
Alike license. (http://creativecommons.org/licenses/by-sa/1.0)
1	klieber	1.2	GLEP: 19
2			Title: Gentoo Stable Portage Tree
3	klieber	1.7	Version: $Revision: 1.7 $
4			Last-Modified: $Date: 2004/11/02 15:38:58 $
5	klieber	1.1	Author: Kurt Lieber <klieber@gentoo.org>
6			Status: Draft
7			Type: Standards Track
8			Content-Type: text/x-rst
9			Created: 26-Jan-2004
10	klieber	1.7	Post-History: 29-Jan-2004 2-Nov-2004 7-Dec-2004
11	klieber	1.1
12
13			Abstract
14			========
15
16			This GLEP is intended to propose a series of changes to the Portage tree that
17			are necessary to facilitate the use of Gentoo in areas where stability and
18			predictability are of paramount importance, including servers in enterprise
19			environments, mission critical workstations and other such installations.
20
21			The proposed solution involves creating a separate tree in Portage that is
22			updated far less often than the regular tree. Outside of periodic updates,
23			this tree would only be updated with critical bugfixes and security patches.
24
25	g2boojum	1.6	Status
26			======
27
28			Currently recruiting people who would be willing to help with this GLEP.
29
30	klieber	1.1	Motivation
31			==========
32
33	klieber	1.5	Enterprise users typically value stability and a predictable upgrade path
34	klieber	1.1	over having the latest packages or features available to them. Historically,
35			Gentoo Linux has been unable to provide such an environment due to the dynamic
36			nature of the Portage tree.
37
38			Specification
39			=============
40
41			The Gentoo Infrastructure team will need to provide an additional Portage tree
42			on our rsync mirroring system. This new tree will house the ebuilds
43			associated with the stable tree. It also impacts all Gentoo developers
44			responsible for creating and updating ebuilds as they will be expected to
45			integrate the tagging of ebuilds for the stable tree into their normal
46			development process, both for the quarterly release cycles as well as
47			off-cycle bug and security fixes.
48
49			The Gentoo Documentation team will also be affected as they will be
50			responsible for updating installation documents to take these new features
51			into account.
52
53			Rationale
54			=========
55
56			A basic outline of various ways of adding a "stable" tree to Portage was
57			discussed in the gentoo managers meeting on 26-Jan-04. Consensus seemed to be
58			reached that such a solution was needed and that branching the gentoo-x86
59			repository was the appropriate way to accomplish this. The largest area of
60			disagreement surrounded how specific ebuilds should be targeted for inclusion
61			in the stable tree.
62
63			One suggested solution was a simple branch of the CVS tree and having
64			developers work in two separate branches; one for the stable tree and
65			another for the traditional tree. However, it was felt this would prove too
66			cumbersome in practice.
67
68			Another suggestion was to have a small group of dedicated gentoo-server
69			developers responsible for generating the contents of the stable tree, which
70			would provide more control and quality assurance over the ebuilds added to the
71			stable tree. While this might prove effective for a small number of ebuilds,
72			it is quite likely that this model would not scale enough to allow for a large
73			number of ebuilds in the stable tree and, over time, the project would become
74			resource constrained and unable to meed future deadlines.
75
76	klieber	1.7	While the original draft of this GLEP called for the creation of a stable
77			keyword, we have since discarded that idea in favor of creating a custom
78			profile, which will be used to track a subset of packages and versions.
79	klieber	1.1
80			Implementation
81			==============
82
83	klieber	1.7	This GLEP will create a new set of cascaded profiles (one per release, not to
84			exceed two per year) which will contain a subset of packages, including
85			versions. This profile will "pin" a Gentoo Linux box to a specific set of
86			packages and will only be updated for security updates and, in rare
87			circumstances, major bug fixes.
88
89			Because this profile will be cascaded, the option exists for other developers
90			to create their own profile, containing a subset of packages not found in the
91			"main" stable tree and include those as part of the overall stable profile.
92			These cases will be treated on a one-off basis.
93
94			The initial version will be x86 only, though other people will be encouraged
95			to provide separate stable profiles for other arches. It is expected that any
96			effort to provide a stable tree for any arch or flavor of Gentoo will follow
97			the basic outline of this GLEP to ensure consistency for our users.
98
99			In addition to a custom profile, this GLEP will also create a separate rsync
100			repository, "gentoo-stable-portage", which will be available on all servers in
101			the rsync.gentoo.org rotation. This repository will be identical to the
102			main gentoo-portage repository except that the --delete flag will be removed
103			from the rsync option that populates the tree. This will ensure that users of
104			the stable profile will not have to worry about ebuilds for their packages
105			disappearing.
106
107			Stable profiles will be maintained on an N - 2 basis. That is to say that we
108			will maintain a stable profile for the most current release, plus the previous
109			two releases. With the expected release schedule for 2005, this will result
110			in each profile being supported for approximately 18 months. Future versions
111			of the stable portage tree may seek to increase the life of these profiles.
112	klieber	1.1
113			Backwards Compatibility
114			=======================
115
116			All features proposed here are new additions to existing processes and
117			features. There should be no impact on existing features and functionality.
118
119
120			Copyright
121			=========
122
123			This document is licensed under the Creative Commons - Attribution / Share
124			Alike license. (http://creativecommons.org/licenses/by-sa/1.0)