| 1 |
GLEP: 19 |
| 2 |
Title: Gentoo Stable Portage Tree |
| 3 |
Version: $Revision: 1.1 $ |
| 4 |
Last-Modified: $Date: 2004/01/27 01:50:51 $ |
| 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 |
| 11 |
|
| 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 |
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. |
| 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 |
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. |
| 78 |
|
| 79 |
Implementation |
| 80 |
============== |
| 81 |
|
| 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: |
| 85 |
|
| 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 |
| 89 |
|
| 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: |
| 93 |
|
| 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.) |
| 97 |
|
| 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. |
| 100 |
|
| 101 |
Backwards Compatibility |
| 102 |
======================= |
| 103 |
|
| 104 |
All features proposed here are new additions to existing processes and |
| 105 |
features. There should be no impact on existing features and functionality. |
| 106 |
|
| 107 |
|
| 108 |
Copyright |
| 109 |
========= |
| 110 |
|
| 111 |
This document is licensed under the Creative Commons - Attribution / Share |
| 112 |
Alike license. (http://creativecommons.org/licenses/by-sa/1.0) |
Parent Directory
| 
Revision Log