| 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