/[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.8 - (hide annotations) (download)
Tue Oct 10 16:54:34 2006 UTC (8 years ago) by g2boojum
Branch: MAIN
CVS Tags: HEAD
Changes since 1.7: +8 -3 lines
File MIME type: text/plain
withdraw 19

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

  ViewVC Help
Powered by ViewVC 1.1.20