From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EBvee-0001Ds-Nb for garchives@archives.gentoo.org; Sun, 04 Sep 2005 14:39:33 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j84EZrwg013340; Sun, 4 Sep 2005 14:35:53 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j84EYCWU007834 for ; Sun, 4 Sep 2005 14:34:13 GMT Received: from adsl-70-241-64-171.dsl.hstntx.swbell.net ([70.241.64.171] helo=localhost) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EBvcN-0001Ed-3O for gentoo-dev@lists.gentoo.org; Sun, 04 Sep 2005 14:37:11 +0000 Date: Sun, 4 Sep 2005 09:37:11 -0500 From: Grant Goodyear To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] tentative x86 arch team glep Message-ID: <20050904143711.GD23576@dst.grantgoodyear.org> Mail-Followup-To: gentoo-dev@gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KlAEzMkarCnErv5Q" Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Archives-Salt: 108eee13-585a-4d2f-a230-07f39cd100a6 X-Archives-Hash: e3aa2aa97b6552eb4b0a66088333ae9a --KlAEzMkarCnErv5Q Content-Type: multipart/mixed; boundary="76DTJ5CE0DCVQemd" Content-Disposition: inline --76DTJ5CE0DCVQemd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear all, Here's a GLEP that I'm thinking about right now. It's not yet official, since I'd like to get some feedback beforehand (which helps to ensure that I'm not abusing my GLEP-editor powers). If you have additional arguments either pro or con, please send them my way so that I may incorporate them. Best, g2boojum --=20 Grant Goodyear=09 Gentoo Developer g2boojum@gentoo.org http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 --76DTJ5CE0DCVQemd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="glep-0040.txt" Content-Transfer-Encoding: quoted-printable GLEP: 40 Title: Standardizing "arch" keywording across all archs. Version: $Revision: 1.8 $ Last-Modified: $Date: 2005/01/09 16:12:40 $ Author: Grant Goodyear Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 3-Sep-2005 Post-History: 6-Sep-2005 Credits =3D=3D=3D=3D=3D=3D=3D This GLEP originated from a rather contentious discussion_ on gentoo-dev about combining the x86 and amd64 keywords. This GLEP attempts to get at t= he heart of that discontent. The proposed stable-keyword guidelines have been lifted verbatim from `The Doc`_. =2E. _discussion: http://tinyurl.com/bp859 =2E. _The Doc: http://dev.gentoo.org/~plasmaroo/devmanual Abstract =3D=3D=3D=3D=3D=3D=3D=3D It is time for x86 to no longer be an exception to the standard keywording guidelines. Thus, an x86 arch team should be responsible=20 for moving packages from ~x86 to x86. Motivation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The original, informal x86 keywording policy, where almost any x86 dev (whi= ch were the vast majority of devs) who used a package could mark it stable, ar= ose =66rom a time when there were relatively few Gentoo devs. Adding packages = to the tree was the principal concern, as opposed to maintaining existing packages. QA considerations have since modified that policy slightly, and n= ow it is the package maintainers who should mark an x86 package stable. Of course, that policy presumes that package maintainers are generally x86 dev= s, which is slowly becoming less and less true. This policy for x86 is quite different from how every other arch marks packages stable. For the non-x86 archs, each arch has a specific "arch tea= m" which is responsible for moving packages from ``~arch`` to ``arch``. This approach has worked quite well for the non-x86 archs, and this GLEP asserts that the same approach would benefit x86 as well. Specification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. Thirty days is the usual figure, although this is clearly only a guideli= ne. For critical packages, a much longer duration is expected. For small packages which have only minor changes between versions, a shorter period is sometimes appropriate. * The package must not have any non-``arch`` dependencies. * The package must not have any severe outstanding bugs or issues. * The package must be widely tested. * If the package is a library, it should be known not to break any package which depends upon it. * The relevant ``arch`` team must agree to it. x86 arch team ------------- A robust x86 arch team needs to be created. The x86@gentoo.org alias alrea= dy exists, and it merely needs to be used. This team, with the aid of potenti= al non-dev ``arch testers``, has the responsibility of stabling all x86 packag= es. Current x86 devs who wish to mark their own packages stable must therefore either be members of or make individual arrangements with the x86 arch team. Rationale =3D=3D=3D=3D=3D=3D=3D=3D=3D There will be a considerable one-time cost involved in establishing a=20 robust x86 arch team. Certainly consistency between the various archs would be a virtue, but is it worth the cost involved? Here are the arguments for enduring the pain involved: * Over time, x86 is likely to become a minority arch as 64-bit systems become the norm. The implicit assumptions that underly the current 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.=20 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 litt= le cause to notice that a package has not been marked stable. The much lar= ger effect, though, is that it is rare for ``x86`` packages to be stabled in the context of a full ``x86`` tree, so the big picture of a stable *system*, not just a stable package, is lost. This approach of stabling in the context of a full stable ``arch`` tree, it has been argued_, is the fundamental reason why the non-x86 archs have notably better QA than does the x86 arch. =2E. _argued: http://thread.gmane.org/gmane.linux.gentoo.devel/30369 Implementation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Creation of a robust x86 team is already underway. The more vital step=20 is the official change in policy, along with a sustained effort to get existing x86 devs to go along with it. Backwards Compatibility =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Not really an issue here. Copyright =3D=3D=3D=3D=3D=3D=3D=3D=3D This document has been placed in the public domain. --76DTJ5CE0DCVQemd-- --KlAEzMkarCnErv5Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDGwaXptxxUuD2W3YRAqYYAJ4vvd3FYjPL7Hmhk+zgR1tv3eAJaACfRFzR C/8aFT1LJp1dxtDXK9SeRcQ= =ync2 -----END PGP SIGNATURE----- --KlAEzMkarCnErv5Q-- -- gentoo-dev@gentoo.org mailing list