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 1Lc0R3-0006i1-8G for garchives@archives.gentoo.org; Tue, 24 Feb 2009 16:47:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 27A02E045F; Tue, 24 Feb 2009 16:47:01 +0000 (UTC) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.150]) by pigeon.gentoo.org (Postfix) with ESMTP id F1DD8E045F for ; Tue, 24 Feb 2009 16:47:00 +0000 (UTC) Received: by qw-out-1920.google.com with SMTP id 9so1005697qwj.10 for ; Tue, 24 Feb 2009 08:47:00 -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=Ois2Nv4nP+q4iBkSKtIuA+W3nhvD1qnxDsscwJK+7yU=; b=MhiSnOIDFoWZL1I74p4MSD2eB0le9fK5G4t9RkoC0mq2xjvXbLxCoN9VgzBJG1lpu8 tHIAjOc2MFNBjHLEoD0Z/8egqT3kZAQBGW0WT0Yjq/h1pg1CdP15WQa5q12njJMb5dFV +pnr0KAPhUdLh/ta/pYzpPnB0nLk9hWZ9HWwQ= 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=UQS6imuUA5xBl9+q0nwXFjVkGQl+uMEUZWvyqgL8LLWjLPBgQmpgs/5GRuKcPM4Q7Z mtVX2Hw6Xsq1tRVsOHhPMC++aLfPQ+M7VkY/MoCRyXF2P5e0ffKQfVUljucpg4BQJnfx dI8oJFP2hnZQL+jeJRF8YGquhXTp36HUeVBAc= Received: by 10.224.54.76 with SMTP id p12mr17815qag.207.1235494019237; Tue, 24 Feb 2009 08:46:59 -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 6sm9283290ugc.17.2009.02.24.08.46.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 08:46:58 -0800 (PST) Date: Tue, 24 Feb 2009 16:46:51 +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: <20090224164651.1db2a89c@snowcone> In-Reply-To: <8b4c83ad0902240829k2ee96493hb6c1fae5dcc7d04e@mail.gmail.com> References: <1234257125.18160.2016.camel@localhost> <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> <8b4c83ad0902240829k2ee96493hb6c1fae5dcc7d04e@mail.gmail.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_/ynLSdCHP5gefXjChZL=VLeY"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 24872f92-90ae-4a28-a651-1cf6177c93cd X-Archives-Hash: cf9b227c608f62aa00ba8b9c3d71933f --Sig_/ynLSdCHP5gefXjChZL=VLeY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Feb 2009 21:59:39 +0530 Nirbheek Chauhan wrote: > On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh > wrote: > > ...and it means we can't change name or version rules. >=20 > And has such a case come to light recently where it was *essential* to > do so? Why solve problems that don't exist? Because they do exist, which is why name and version rules have been changed the hard way at least twice previously. The version format is still considerably less flexible than what upstreams use, and a lot of the current limitations on its format are purely historical. > > ...and it means we can't make arbitrary format changes. >=20 > What? Why are we over-engineering this? Does anyone seriously want to > convert ebuilds to XML? I honestly think anything beyond incremental > changes is not relevant for Gentoo You appear to be confusing arbitrary format changes with doing a Zynot. The two are not the same. > > 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 > That's a documentation problem. No, it's a design problem. Good design looks for ways to minimise the amount of unnecessary arbitrary information the user has to remember. --=20 Ciaran McCreesh --Sig_/ynLSdCHP5gefXjChZL=VLeY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkJH4ACgkQ96zL6DUtXhFn1wCcD3ClgDmRsO55BezI7Chq/fGT T+0An18Ifj/f8szVQYx1eRJanCRNwdqI =Rdpy -----END PGP SIGNATURE----- --Sig_/ynLSdCHP5gefXjChZL=VLeY--