/[gentoo]/xml/htdocs/proj/en/glep/glep-0019.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0019.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.6 - (hide annotations) (download)
Tue Nov 2 15:38:58 2004 UTC (9 years, 11 months ago) by g2boojum
Branch: MAIN
Changes since 1.5: +8 -3 lines
File MIME type: text/plain
update

1 klieber 1.2 GLEP: 19
2     Title: Gentoo Stable Portage Tree
3 g2boojum 1.6 Version: $Revision: 1.5 $
4     Last-Modified: $Date: 2004/02/02 18:16:31 $
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.6 Post-History: 29-Jan-2004 2-Nov-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     The suggestion that seemed to get the most traction was the creation of a new
77     "stable" keyword which would be added to appropriate ebuilds. The use of
78     "stable" would signify ebuilds that are ready for production in the stable
79 g2boojum 1.4 tree while "~stable" would be reserved for ebuilds which may be appropriate
80 klieber 1.1 for the stable tree, but may require further testing before being deemed
81     "ready for production". Off-cycle bug fixes and/or security updates may be
82 klieber 1.5 examples of ebuilds that require the ~stable tag.
83 klieber 1.1
84     Implementation
85     ==============
86    
87 klieber 1.3 While a 'stable' keyword was originally proposed, after further review, it was
88     determined this offered no way to allow arch-specific stable ebuilds. As
89     such, this GLEP proposes the use of 'stable:<arch>' and '~stable:<arch>'
90     (stable:x86, stable:ppc, etc.)
91    
92     A new, stable tree will be created by scanning for the 'stable:<arch>' and
93     '~stable:<arch>' keywords in the ebuilds and pulling those ebuilds and
94     associated files into a separate branch of CVS. The stable tree should have
95     the following features:
96 klieber 1.1
97     * Updated quarterly. Frozen during other times except for security/bug fixes
98 klieber 1.3 * All ebuilds should remain in the tree for a minimum of one year. This
99     allows users to upgrade as infrequently as once per year without risking
100     the stable portage tree leaving them behind without an upgrade path.
101 klieber 1.1
102     As mentioned above, the "stable" tree will be updated quarterly, ideally in
103     unison with the release schedule of the main Gentoo branch. This tree will be
104     untouched outside of this update schedule except in the following cases:
105    
106     * Security fixes and patches which result in a GLSA
107     * Bug fixes for bugs ranked as 'maj' or above (may be overridden at the
108     discretion of the package maintainer.)
109    
110     In both cases, the maintainer of the package will be responsible for ensuring
111     these patches are properly committed to the stable tree out of cycle.
112    
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)

  ViewVC Help
Powered by ViewVC 1.1.20