| 1 |
GLEP: 40
|
| 2 |
Title: Standardizing "arch" keywording across all archs.
|
| 3 |
Version: $Revision: 1.3 $
|
| 4 |
Last-Modified: $Date: 2005/11/13 17:16:50 $
|
| 5 |
Author: Grant Goodyear <g2boojum@gentoo.org>
|
| 6 |
Status: Final
|
| 7 |
Type: Standards Track
|
| 8 |
Content-Type: text/x-rst
|
| 9 |
Created: 3-Sep-2005
|
| 10 |
Post-History: 6-Sep-2005 15-Sep-2005 3-Sep-2006
|
| 11 |
|
| 12 |
Status
|
| 13 |
======
|
| 14 |
|
| 15 |
Approved by the Gentoo Council on 15 September 2005. As of 20060903
|
| 16 |
we have a robust x86 arch team, so this GLEP is final
|
| 17 |
|
| 18 |
Credits
|
| 19 |
=======
|
| 20 |
|
| 21 |
This GLEP originated from a rather contentious discussion_ on gentoo-dev
|
| 22 |
about combining the x86 and amd64 keywords. This GLEP attempts to get at the
|
| 23 |
heart of that discontent. The proposed stable-keyword guidelines have been
|
| 24 |
lifted verbatim from `The Doc`_.
|
| 25 |
|
| 26 |
.. _discussion: http://tinyurl.com/bp859
|
| 27 |
.. _The Doc: http://dev.gentoo.org/~plasmaroo/devmanual
|
| 28 |
|
| 29 |
Abstract
|
| 30 |
========
|
| 31 |
|
| 32 |
It is time for x86 to no longer be an exception to the standard
|
| 33 |
keywording guidelines. Thus, an x86 arch team should be responsible
|
| 34 |
for moving packages from ~x86 to x86.
|
| 35 |
|
| 36 |
Motivation
|
| 37 |
==========
|
| 38 |
|
| 39 |
The original, informal x86 keywording policy, where almost any x86 dev (which
|
| 40 |
were the vast majority of devs) who used a package could mark it stable, arose
|
| 41 |
from a time when there were relatively few Gentoo devs. Adding packages to
|
| 42 |
the tree was the principal concern, as opposed to maintaining existing
|
| 43 |
packages. QA considerations have since modified that policy slightly, and now
|
| 44 |
it is the package maintainers who should mark an x86 package stable. Of
|
| 45 |
course, that policy presumes that package maintainers are generally x86 devs,
|
| 46 |
which is slowly becoming less and less true.
|
| 47 |
|
| 48 |
This policy for x86 is quite different from how every other arch marks
|
| 49 |
packages stable. For the non-x86 archs, each arch has a specific "arch team"
|
| 50 |
which is responsible for moving packages from ``~arch`` to ``arch``, although
|
| 51 |
vapier notes that "arch teams generally defer to maintainers (and rightly so)
|
| 52 |
as to *when* newer versions should go stable." This approach has worked quite
|
| 53 |
well for the non-x86 archs, and this GLEP asserts that the same approach would
|
| 54 |
benefit x86 as well.
|
| 55 |
|
| 56 |
Specification
|
| 57 |
=============
|
| 58 |
|
| 59 |
Stabling guidelines for all archs
|
| 60 |
---------------------------------
|
| 61 |
|
| 62 |
For a package to move to stable, the following guidelines must be met:
|
| 63 |
|
| 64 |
* The package has spent a reasonable amount of time in ``~arch`` first.
|
| 65 |
Thirty days is the usual figure, although this is clearly only a guideline.
|
| 66 |
For critical packages, a much longer duration is expected. For small
|
| 67 |
packages which have only minor changes between versions, a shorter period
|
| 68 |
is sometimes appropriate.
|
| 69 |
* The package must not have any non-``arch`` dependencies.
|
| 70 |
* The package must not have any severe outstanding bugs or issues.
|
| 71 |
* The package must be widely tested.
|
| 72 |
* If the package is a library, it should be known not to break any package
|
| 73 |
which depends upon it.
|
| 74 |
* The relevant ``arch`` team must agree to it.
|
| 75 |
|
| 76 |
x86 arch team
|
| 77 |
-------------
|
| 78 |
|
| 79 |
A robust x86 arch team needs to be created. The x86@gentoo.org alias already
|
| 80 |
exists, and it merely needs to be used. This team, with the aid of potential
|
| 81 |
non-dev ``arch testers``, has the responsibility of stabling all x86 packages.
|
| 82 |
Current x86 devs who wish to mark their own packages stable must therefore
|
| 83 |
either be members of or make individual arrangements with the x86 arch team.
|
| 84 |
|
| 85 |
|
| 86 |
Rationale
|
| 87 |
=========
|
| 88 |
|
| 89 |
There will be a considerable one-time cost involved in establishing a robust
|
| 90 |
x86 arch team--a good number of bodies (the amd64 arch team has 19 active devs
|
| 91 |
and 12 active non-dev arch testers) need to be recruited to be part of the
|
| 92 |
new arch team, and convincing devs that it is in their best interests to work
|
| 93 |
in a new fashion is likely to be even harder. Certainly the benefit of
|
| 94 |
consistency between the various archs is obvious, but is it worth the cost
|
| 95 |
involved? Here are the arguments for enduring the pain involved:
|
| 96 |
|
| 97 |
* Over time, x86 is likely to become a minority arch as 64-bit systems
|
| 98 |
become the norm. The implicit assumptions that underly the current
|
| 99 |
system (that most devs, users, and package maintainers use x86)
|
| 100 |
will become increasingly less valid.
|
| 101 |
* Markedly improved QA for x86. Assuming that the author's own is
|
| 102 |
behavior is representative, most x86 devs run ``~x86`` systems.
|
| 103 |
Thus, the assumption that devs are good ``x86`` testers is not really
|
| 104 |
valid. One obvious consequence is that packages tend to languish in
|
| 105 |
``~x86`` for a very long time, since x86 devs running ``~x86`` have little
|
| 106 |
cause to notice that a package has not been marked stable. The much larger
|
| 107 |
effect, though, is that it is rare for ``x86`` packages to be stabled in
|
| 108 |
the context of a full ``x86`` tree, so the big picture of a stable
|
| 109 |
*system*, not just a stable package, is lost. This approach of stabling
|
| 110 |
in the context of a full stable ``arch`` tree, it has been argued_, is
|
| 111 |
the fundamental reason why the non-x86 archs have notably better QA
|
| 112 |
than does the x86 arch.
|
| 113 |
|
| 114 |
.. _argued: http://thread.gmane.org/gmane.linux.gentoo.devel/30369
|
| 115 |
|
| 116 |
Implementation
|
| 117 |
==============
|
| 118 |
|
| 119 |
Creation of a robust x86 team is already underway. The more vital step
|
| 120 |
is the official change in policy, along with a sustained effort to get
|
| 121 |
existing x86 devs to go along with it.
|
| 122 |
|
| 123 |
Alternative Ideas
|
| 124 |
=================
|
| 125 |
|
| 126 |
Stuart_ has suggested the creation of a new arch keyword: "[-]maint", which
|
| 127 |
would exist in tandem with the normal arch keywords, thereby making the
|
| 128 |
package maintainer's intention explicit. Ciaranm has responded that by
|
| 129 |
definition a package in ``~arch`` is a candidate for ``arch``, so a package's
|
| 130 |
mere presence in the tree (without being in ``package.mask``) should indicate
|
| 131 |
the package maintainer's intention. There was a fair bit of discussion about
|
| 132 |
whether the idea should be a "maint" keyword, or named something else, or an
|
| 133 |
entirely different variable, etcetera, but the basic gist didn't change much.
|
| 134 |
|
| 135 |
Jstubbs notes that it could be a very good idea if all non-arch devs worked in
|
| 136 |
overlays, but that new portage (gensync) support would be needed to make it
|
| 137 |
truly viable. Stuart pointed out that php5 support was handled just that way.
|
| 138 |
One author's view is that this approach would make the "package in ``~arch``
|
| 139 |
means that it's a de-facto candidate for ``arch``" interpretation even more
|
| 140 |
valid.
|
| 141 |
|
| 142 |
Ciaranm and weeve have noted that it is occasionally necessary for arch teams
|
| 143 |
to override a package maintainer when it comes to stabling a package. Stuart
|
| 144 |
has asserted that in those cases the arch team should be willing to take on
|
| 145 |
the support burden for that package.
|
| 146 |
|
| 147 |
.. _Stuart: http://thread.gmane.org/gmane.linux.gentoo.devel/31060
|
| 148 |
|
| 149 |
Backwards Compatibility
|
| 150 |
=======================
|
| 151 |
|
| 152 |
Not really an issue here.
|
| 153 |
|
| 154 |
|
| 155 |
Copyright
|
| 156 |
=========
|
| 157 |
|
| 158 |
This document has been placed in the public domain.
|
Parent Directory
| 
Revision Log