From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Lc42C-0001s9-VU for garchives@archives.gentoo.org; Tue, 24 Feb 2009 20:37:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E516FE0529; Tue, 24 Feb 2009 20:37:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id ADEBFE0529 for ; Tue, 24 Feb 2009 20:37:43 +0000 (UTC) Received: from vrm378-02.vrm378.am.mot.com (unknown [144.190.95.61]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 15A9F64899 for ; Tue, 24 Feb 2009 20:37:42 +0000 (UTC) Date: Tue, 24 Feb 2009 15:37:36 -0500 From: Jim Ramsay To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090224153736.71804732@vrm378-02.vrm378.am.mot.com> In-Reply-To: <20090224201319.173144e6@snowcone> References: <1234257125.18160.2016.camel@localhost> <20090212161644.GD3642@comet> <20090212162103.256b003f@snowcone> <20090212171055.GA3652@comet> <20090212172109.778fb268@snowcone> <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <49A39CE7.4010201@gentoo.org> <49A3AAA1.6080207@gentoo.org> <49A3B947.2020907@gentoo.org> <49A3D0F6.6080307@gentoo.org> <49A41656.7020100@gentoo.org> <20090224155654.602f6c88@snowcone> <20090224122527.1e800f30@vrm378-02.vrm378.am.mot.com> <20090224182023.5d858986@snowcone> <20090224140845.73053f4c@vrm378-02.vrm378.am.mot.com> <20090224191928.6b9e52db@snowcone> <20090224150729.2c83596f@vrm378-02.vrm378.am.mot.com> <20090224201319.173144e6@snowcone> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/bcMj7OyItFT8i8rlhpY2Pq9"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 350d7b5b-f27f-4b2d-8851-a73e86447247 X-Archives-Hash: 09668055b405460156692ccd0101932b --Sig_/bcMj7OyItFT8i8rlhpY2Pq9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ciaran McCreesh wrote: > On Tue, 24 Feb 2009 15:07:29 -0500 > Jim Ramsay wrote: > > I think > > things are very nicely documented in PMS and the devmanual, which > > are where all EAPI changes should be documented in the future, > > regardless if you specify the EAPI in the file, the extension, or > > both. >=20 > They only ended up nicely documented after people moaned a lot that > they were having a hard time keeping track of EAPIs... You can't possibly be suggesting that everyone will be able to keep an ever-increasing number of feature sets in his or her mind, or that changing from a two-level to a one-level EAPI definition will remove the need for documentation going forward, so I'm not sure what you mean by this. > > Two levels really just means that any fancy tables will have to have > > one extra row (or perhaps a series of fancy tables) and any > > summaries will have to have an extra section added whenever a new > > filename extension becomes necessary. >=20 > It'll mean people will carry on having to use the tables, and won't > start remembering things as time goes on. See comment above. The need for documentation will only increase going forward as new and varied EAPI definitions are created. > > If I understand the '.eapi3.eb' to which you make passing reference, > > this is just a fancy hand-wavy way to say "Look, the true .eb > > extension won't ever change, just the .eapi3 part which isn't > > technically the extension..." which isn't a compromise at all - It's > > an attempt to (cleverly?) obfuscate where in the filename the EAPI > > is stored. >=20 > Yup. And yet there're people who are perfectly happy with .eapi3.eb > who hate GLEP 55. That should tell you all you need to know about > what's going on here... Seriously? That's scary. But hey, if that's actually going to get more people behind this, let's do it instead. --=20 Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) --Sig_/bcMj7OyItFT8i8rlhpY2Pq9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmkWpMACgkQelWXok6VKugUDwCePOyBeYY5Xazd1DG3OiKZ2Bx0 HqMAoL17CuaboPLo7BAxHN4RRGZhCSyn =+rwb -----END PGP SIGNATURE----- --Sig_/bcMj7OyItFT8i8rlhpY2Pq9--