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