diff options
Diffstat (limited to 'glep-0019.rst')
| -rw-r--r-- | glep-0019.rst | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/glep-0019.rst b/glep-0019.rst new file mode 100644 index 0000000..27369b4 --- /dev/null +++ b/glep-0019.rst @@ -0,0 +1,125 @@ +GLEP: 19 +Title: Gentoo Stable Portage Tree +Version: $Revision$ +Last-Modified: $Date$ +Author: Kurt Lieber <klieber@gentoo.org> +Status: Withdrawn +Type: Standards Track +Content-Type: text/x-rst +Created: 26-Jan-2004 +Post-History: 29-Jan-2004 2-Nov-2004 7-Dec-2004 10-Oct-2006 + +Status +====== + +Withdrawn by the author. "If someone wants to take up the torch, more +power to them, but they should probably start clean with a new glep." + +Abstract +======== + +This GLEP is intended to propose a series of changes to the Portage tree that +are necessary to facilitate the use of Gentoo in areas where stability and +predictability are of paramount importance, including servers in enterprise +environments, mission critical workstations and other such installations. + +The proposed solution involves creating a separate tree in Portage that is +updated far less often than the regular tree. Outside of periodic updates, +this tree would only be updated with critical bugfixes and security patches. + +Motivation +========== + +Enterprise users typically value stability and a predictable upgrade path +over having the latest packages or features available to them. Historically, +Gentoo Linux has been unable to provide such an environment due to the dynamic +nature of the Portage tree. + +Specification +============= + +The Gentoo Infrastructure team will need to provide an additional Portage tree +on our rsync mirroring system. This new tree will house the ebuilds +associated with the stable tree. It also impacts all Gentoo developers +responsible for creating and updating ebuilds as they will be expected to +integrate the tagging of ebuilds for the stable tree into their normal +development process, both for the quarterly release cycles as well as +off-cycle bug and security fixes. + +The Gentoo Documentation team will also be affected as they will be +responsible for updating installation documents to take these new features +into account. + +Rationale +========= + +A basic outline of various ways of adding a "stable" tree to Portage was +discussed in the gentoo managers meeting on 26-Jan-04. Consensus seemed to be +reached that such a solution was needed and that branching the gentoo-x86 +repository was the appropriate way to accomplish this. The largest area of +disagreement surrounded how specific ebuilds should be targeted for inclusion +in the stable tree. + +One suggested solution was a simple branch of the CVS tree and having +developers work in two separate branches; one for the stable tree and +another for the traditional tree. However, it was felt this would prove too +cumbersome in practice. + +Another suggestion was to have a small group of dedicated gentoo-server +developers responsible for generating the contents of the stable tree, which +would provide more control and quality assurance over the ebuilds added to the +stable tree. While this might prove effective for a small number of ebuilds, +it is quite likely that this model would not scale enough to allow for a large +number of ebuilds in the stable tree and, over time, the project would become +resource constrained and unable to meed future deadlines. + +While the original draft of this GLEP called for the creation of a stable +keyword, we have since discarded that idea in favor of creating a custom +profile, which will be used to track a subset of packages and versions. + +Implementation +============== + +This GLEP will create a new set of cascaded profiles (one per release, not to +exceed two per year) which will contain a subset of packages, including +versions. This profile will "pin" a Gentoo Linux box to a specific set of +packages and will only be updated for security updates and, in rare +circumstances, major bug fixes. + +Because this profile will be cascaded, the option exists for other developers +to create their own profile, containing a subset of packages not found in the +"main" stable tree and include those as part of the overall stable profile. +These cases will be treated on a one-off basis. + +The initial version will be x86 only, though other people will be encouraged +to provide separate stable profiles for other arches. It is expected that any +effort to provide a stable tree for any arch or flavor of Gentoo will follow +the basic outline of this GLEP to ensure consistency for our users. + +In addition to a custom profile, this GLEP will also create a separate rsync +repository, "gentoo-stable-portage", which will be available on all servers in +the rsync.gentoo.org rotation. This repository will be *identical* to the +main gentoo-portage repository except that the --delete flag will be removed +from the rsync option that populates the tree. This will ensure that users of +the stable profile will not have to worry about ebuilds for their packages +disappearing. + +Stable profiles will be maintained on an N - 2 basis. That is to say that we +will maintain a stable profile for the most current release, plus the previous +two releases. With the expected release schedule for 2005, this will result +in each profile being supported for approximately 18 months. Future versions +of the stable portage tree may seek to increase the life of these profiles. + +Backwards Compatibility +======================= + +All features proposed here are new additions to existing processes and +features. There should be no impact on existing features and functionality. + + +Copyright +========= + +This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 +Unported License. To view a copy of this license, visit +http://creativecommons.org/licenses/by-sa/3.0/. |