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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (show annotations) (download)
Tue Jan 27 01:50:51 2004 UTC (14 years, 1 month ago) by klieber
Branch: MAIN
File MIME type: text/plain
really rough first draft

1 GLEP: 18
2 Title: Gentoo Bimonthly Publication
3 Version: $Revision: 1.0 $
4 Last-Modified: $Date: 2004/01/26 23:28:23 $
5 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 Post-History: 26-Jan-2004
13 Abstract
14 ========
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.
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.
25 Motivation
26 ==========
28 Enterprise customers typically value stability and a predictable upgrade path
29 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.
33 Specification
34 =============
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.
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.
48 Rationale
49 =========
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.
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.
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.
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 tree whils "~stable" would be reserved for ebuilds which may be appropriate
75 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 examples of ebuilds that require the ~server tag.
79 Implementation
80 ==============
82 A new, stable tree will be created by scanning for the 'server' and '~server'
83 keywords in the ebuilds and pulling those ebuilds and associated files into a
84 separate branch of CVS. The stable tree should have the following features:
86 * Updated quarterly. Frozen during other times except for security/bug fixes
87 * All ebuilds should remain in the tree for a minimum of one year to ensure
88 that administrators will know how often their servers need to be upgraded
90 As mentioned above, the "stable" tree will be updated quarterly, ideally in
91 unison with the release schedule of the main Gentoo branch. This tree will be
92 untouched outside of this update schedule except in the following cases:
94 * Security fixes and patches which result in a GLSA
95 * Bug fixes for bugs ranked as 'maj' or above (may be overridden at the
96 discretion of the package maintainer.)
98 In both cases, the maintainer of the package will be responsible for ensuring
99 these patches are properly committed to the stable tree out of cycle.
101 Backwards Compatibility
102 =======================
104 All features proposed here are new additions to existing processes and
105 features. There should be no impact on existing features and functionality.
108 Copyright
109 =========
111 This document is licensed under the Creative Commons - Attribution / Share
112 Alike license. (http://creativecommons.org/licenses/by-sa/1.0)

  ViewVC Help
Powered by ViewVC 1.1.20