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