--- xml/htdocs/proj/en/glep/glep-0040.html 2005/09/15 21:04:13 1.2 +++ xml/htdocs/proj/en/glep/glep-0040.html 2006/09/04 03:10:56 1.3 @@ -8,9 +8,252 @@ --> - + GLEP 40 -- Standardizing "arch" keywording across all archs. - + @@ -32,27 +275,27 @@ - + - + - + - + - +
Title:Standardizing "arch" keywording across all archs.
Version:1.2
Version:1.4
Last-Modified:2005/09/15 21:02:11
Last-Modified:2006/09/04 03:09:50
Author:Grant Goodyear <g2boojum at gentoo.org>
Status:Approved
Status:Final
Type:Standards Track
Content-Type:text/x-rst
Content-Type:text/x-rst
Created:3-Sep-2005
Post-History:6-Sep-2005 15-Sep-2005
Post-History:6-Sep-2005 15-Sep-2005 3-Sep-2006

-
-

Contents

+
+

Contents

-
-

Status

-

Approved by the Gentoo Council on 15 September 2005.

+
+

Status

+

Approved by the Gentoo Council on 15 September 2005. As of 20060903 +we have a robust x86 arch team, so this GLEP is final

-
-

Credits

+
+

Credits

This GLEP originated from a rather contentious discussion [1] on gentoo-dev about combining the x86 and amd64 keywords. This GLEP attempts to get at the heart of that discontent. The proposed stable-keyword guidelines have been lifted verbatim from The Doc [2].

-
-

Abstract

+
+

Abstract

It is time for x86 to no longer be an exception to the standard -keywording guidelines. Thus, an x86 arch team should be responsible +keywording guidelines. Thus, an x86 arch team should be responsible for moving packages from ~x86 to x86.

-
-

Motivation

+
+

Motivation

The original, informal x86 keywording policy, where almost any x86 dev (which were the vast majority of devs) who used a package could mark it stable, arose from a time when there were relatively few Gentoo devs. Adding packages to @@ -106,10 +350,10 @@ well for the non-x86 archs, and this GLEP asserts that the same approach would benefit x86 as well.

-
-

Specification

-
-

Stabling guidelines for all archs

+
+

Specification

+
+

Stabling guidelines for all archs

For a package to move to stable, the following guidelines must be met:

  • The package has spent a reasonable amount of time in ~arch first. @@ -125,8 +369,8 @@
  • The relevant arch team must agree to it.
-
-

x86 arch team

+
+

x86 arch team

A robust x86 arch team needs to be created. The x86@gentoo.org alias already exists, and it merely needs to be used. This team, with the aid of potential non-dev arch testers, has the responsibility of stabling all x86 packages. @@ -134,10 +378,10 @@ either be members of or make individual arrangements with the x86 arch team.

-
-

Rationale

+
+

Rationale

There will be a considerable one-time cost involved in establishing a robust -x86 arch team--a good number of bodies (the amd64 atch team has 19 active devs +x86 arch team--a good number of bodies (the amd64 arch team has 19 active devs and 12 active non-dev arch testers) need to be recruited to be part of the new arch team, and convincing devs that it is in their best interests to work in a new fashion is likely to be even harder. Certainly the benefit of @@ -149,7 +393,7 @@ system (that most devs, users, and package maintainers use x86) will become increasingly less valid.

  • Markedly improved QA for x86. Assuming that the author's own is -behavior is representative, most x86 devs run ~x86 systems. +behavior is representative, most x86 devs run ~x86 systems. Thus, the assumption that devs are good x86 testers is not really valid. One obvious consequence is that packages tend to languish in ~x86 for a very long time, since x86 devs running ~x86 have little @@ -162,15 +406,15 @@ than does the x86 arch.
  • -
    -

    Implementation

    -

    Creation of a robust x86 team is already underway. The more vital step +

    +

    Implementation

    +

    Creation of a robust x86 team is already underway. The more vital step is the official change in policy, along with a sustained effort to get existing x86 devs to go along with it.

    -
    -

    Alternative Ideas

    -

    Stuart [4] has suggested the creation of a new arch keyword: "[-]maint", which +

    +

    Alternative Ideas

    +

    Stuart [4] has suggested the creation of a new arch keyword: "[-]maint", which would exist in tandem with the normal arch keywords, thereby making the package maintainer's intention explicit. Ciaranm has responded that by definition a package in ~arch is a candidate for arch, so a package's @@ -182,19 +426,19 @@ overlays, but that new portage (gensync) support would be needed to make it truly viable. Stuart pointed out that php5 support was handled just that way. One author's view is that this approach would make the "package in ~arch -means that it's a de-facto candidate for arch" interpretation even more +means that it's a de-facto candidate for arch" interpretation even more valid.

    Ciaranm and weeve have noted that it is occasionally necessary for arch teams to override a package maintainer when it comes to stabling a package. Stuart has asserted that in those cases the arch team should be willing to take on the support burden for that package.

    -
    -

    Backwards Compatibility

    +
    +

    Backwards Compatibility

    Not really an issue here.

    -
    -

    References

    +
    +

    References

    @@ -220,8 +464,8 @@
    -