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 1Lc1tf-0006lB-3j for garchives@archives.gentoo.org; Tue, 24 Feb 2009 18:20:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D4671E0652; Tue, 24 Feb 2009 18:20:44 +0000 (UTC) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.154]) by pigeon.gentoo.org (Postfix) with ESMTP id AFF97E0652 for ; Tue, 24 Feb 2009 18:20:44 +0000 (UTC) Received: by yw-out-1718.google.com with SMTP id 4so1070697ywq.46 for ; Tue, 24 Feb 2009 10:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=ejeR7BmOYzMZsebrJmK50dI3yuDkibyVy7JI5DvveoE=; b=a0JoV4QDLRYqXR8vA2P1AlDXm2INXYdbyL9ALcZ/MzgMxHotgRiVNgx7r+QG3QNYZO fXuR64prUKKqXMVMgghDvVy7M27+FHq0Spxm7ANE4X/A8DtlQZlUCYhkwVNJgL37ijt5 uhjvgAO8eAZkBBRiMGC4kspTLXq9itcapYzW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=WzwBdrHQbxFEjzk7FB6PG4+Mh5FiumOi3seIcPI27lnOzZemGrRfFj/HphmFrYCSAA qJhFFVEboVvfyuLCD/E2VlyE3IUJNdHx0S7reRXBVb3sNJm2SirUBp1I9Tly9EP4eCVl mqT8M+4p/pJv92vm/3dqcUVHs/Q5hvCG7Hyqk= Received: by 10.151.103.11 with SMTP id f11mr42388ybm.21.1235499644346; Tue, 24 Feb 2009 10:20:44 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id o24sm307509ugd.27.2009.02.24.10.20.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 10:20:43 -0800 (PST) Date: Tue, 24 Feb 2009 18:20:23 +0000 From: Ciaran McCreesh 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: <20090224182023.5d858986@snowcone> In-Reply-To: <20090224122527.1e800f30@vrm378-02.vrm378.am.mot.com> References: <1234257125.18160.2016.camel@localhost> <1234450419.20950.2.camel@localhost> <20090212160045.GB3642@comet> <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> 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_/E=PH=G_Z5kzN9S=9JofPvsL"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: fe228e16-5046-4959-8aef-8c185b77ab39 X-Archives-Hash: 305b4e7b6d1de4e46673e9b0ae63b3c6 --Sig_/E=PH=G_Z5kzN9S=9JofPvsL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Feb 2009 12:25:27 -0500 Jim Ramsay wrote: > > ...and it means we can't change name or version rules. > >=20 > > ...and it means over doubling the best possible time to work out a > > dependency tree in the common case where the metadata cache is > > valid. > >=20 > > ...and it means we can't make arbitrary format changes. >=20 > Those would all land in the category of "backwards compatibility" > mentioned below, as they would all break current sourcing rules. No, they're also future issues. Without glep 55, every time they come up we have to go through the whole mess again. > > Developers already have to stop and think and consult the > > conveniently available table of features for EAPIs. By splitting > > the EAPI concept in two you're doubling the amount of data to be > > learnt. > =20 > I would think that this is a very small cost, and the benefit would be > (I hope) that more people would agree on the solution and then we can > go forward. Is that not a valid consideration? I'd expect to see changes that would warrant a major bump in every other EAPI or so anyway, so it's not really worth the complexity. --=20 Ciaran McCreesh --Sig_/E=PH=G_Z5kzN9S=9JofPvsL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkOncACgkQ96zL6DUtXhFMkgCfUM8JlQNuGr8X5+3pIj06zGUh rjoAoOTfMorW/cJJYHh2F/VkhjCVuAh+ =1gG7 -----END PGP SIGNATURE----- --Sig_/E=PH=G_Z5kzN9S=9JofPvsL--