en/glep/glep-0019.txt

GLEP: 19
Title: Gentoo Stable Portage Tree 
Version: $Revision: 1.4 $
Last-Modified: $Date: 2004/01/30 02:41:45 $
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


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.  

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.

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.5	Version: $Revision: 1.4 $
4			Last-Modified: $Date: 2004/01/30 02:41:45 $
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	g2boojum	1.4	Post-History: 29-Jan-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			Motivation
26			==========
27
28	klieber	1.5	Enterprise users typically value stability and a predictable upgrade path
29	klieber	1.1	over having the latest packages or features available to them. Historically,
30			Gentoo Linux has been unable to provide such an environment due to the dynamic
31			nature of the Portage tree.
32
33			Specification
34			=============
35
36			The Gentoo Infrastructure team will need to provide an additional Portage tree
37			on our rsync mirroring system. This new tree will house the ebuilds
38			associated with the stable tree. It also impacts all Gentoo developers
39			responsible for creating and updating ebuilds as they will be expected to
40			integrate the tagging of ebuilds for the stable tree into their normal
41			development process, both for the quarterly release cycles as well as
42			off-cycle bug and security fixes.
43
44			The Gentoo Documentation team will also be affected as they will be
45			responsible for updating installation documents to take these new features
46			into account.
47
48			Rationale
49			=========
50
51			A basic outline of various ways of adding a "stable" tree to Portage was
52			discussed in the gentoo managers meeting on 26-Jan-04. Consensus seemed to be
53			reached that such a solution was needed and that branching the gentoo-x86
54			repository was the appropriate way to accomplish this. The largest area of
55			disagreement surrounded how specific ebuilds should be targeted for inclusion
56			in the stable tree.
57
58			One suggested solution was a simple branch of the CVS tree and having
59			developers work in two separate branches; one for the stable tree and
60			another for the traditional tree. However, it was felt this would prove too
61			cumbersome in practice.
62
63			Another suggestion was to have a small group of dedicated gentoo-server
64			developers responsible for generating the contents of the stable tree, which
65			would provide more control and quality assurance over the ebuilds added to the
66			stable tree. While this might prove effective for a small number of ebuilds,
67			it is quite likely that this model would not scale enough to allow for a large
68			number of ebuilds in the stable tree and, over time, the project would become
69			resource constrained and unable to meed future deadlines.
70
71			The suggestion that seemed to get the most traction was the creation of a new
72			"stable" keyword which would be added to appropriate ebuilds. The use of
73			"stable" would signify ebuilds that are ready for production in the stable
74	g2boojum	1.4	tree while "~stable" would be reserved for ebuilds which may be appropriate
75	klieber	1.1	for the stable tree, but may require further testing before being deemed
76			"ready for production". Off-cycle bug fixes and/or security updates may be
77	klieber	1.5	examples of ebuilds that require the ~stable tag.
78	klieber	1.1
79			Implementation
80			==============
81
82	klieber	1.3	While a 'stable' keyword was originally proposed, after further review, it was
83			determined this offered no way to allow arch-specific stable ebuilds. As
84			such, this GLEP proposes the use of 'stable:<arch>' and '~stable:<arch>'
85			(stable:x86, stable:ppc, etc.)
86
87			A new, stable tree will be created by scanning for the 'stable:<arch>' and
88			'~stable:<arch>' keywords in the ebuilds and pulling those ebuilds and
89			associated files into a separate branch of CVS. The stable tree should have
90			the following features:
91	klieber	1.1
92			* Updated quarterly. Frozen during other times except for security/bug fixes
93	klieber	1.3	* All ebuilds should remain in the tree for a minimum of one year. This
94			allows users to upgrade as infrequently as once per year without risking
95			the stable portage tree leaving them behind without an upgrade path.
96	klieber	1.1
97			As mentioned above, the "stable" tree will be updated quarterly, ideally in
98			unison with the release schedule of the main Gentoo branch. This tree will be
99			untouched outside of this update schedule except in the following cases:
100
101			* Security fixes and patches which result in a GLSA
102			* Bug fixes for bugs ranked as 'maj' or above (may be overridden at the
103			discretion of the package maintainer.)
104
105			In both cases, the maintainer of the package will be responsible for ensuring
106			these patches are properly committed to the stable tree out of cycle.
107
108			Backwards Compatibility
109			=======================
110
111			All features proposed here are new additions to existing processes and
112			features. There should be no impact on existing features and functionality.
113
114
115			Copyright
116			=========
117
118			This document is licensed under the Creative Commons - Attribution / Share
119			Alike license. (http://creativecommons.org/licenses/by-sa/1.0)