Contents of /xml/htdocs/proj/en/glep/glep-0040.txt

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.3 - (hide annotations) (download)
Sun Nov 13 17:16:50 2005 UTC (12 years, 7 months ago) by g2boojum
Branch: MAIN
Changes since 1.2: +3 -3 lines
File MIME type: text/plain
Mark GLEP 43 approved and final

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
12     Status
13     ======
15     Approved by the Gentoo Council on 15 September 2005.
16 g2boojum 1.1
17     Credits
18     =======
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`_.
25     .. _discussion: http://tinyurl.com/bp859
26     .. _The Doc: http://dev.gentoo.org/~plasmaroo/devmanual
28     Abstract
29     ========
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.
35     Motivation
36     ==========
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.
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.
55     Specification
56     =============
58     Stabling guidelines for all archs
59     ---------------------------------
61     For a package to move to stable, the following guidelines must be met:
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.
75     x86 arch team
76     -------------
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.
85     Rationale
86     =========
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:
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.
113     .. _argued: http://thread.gmane.org/gmane.linux.gentoo.devel/30369
115     Implementation
116     ==============
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.
122     Alternative Ideas
123     =================
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.
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.
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.
146     .. _Stuart: http://thread.gmane.org/gmane.linux.gentoo.devel/31060
148     Backwards Compatibility
149     =======================
151     Not really an issue here.
154     Copyright
155     =========
157     This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20