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 <gentoo-dev+bounces-34522-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1Lc0HG-00024J-SB
	for garchives@archives.gentoo.org; Tue, 24 Feb 2009 16:37:05 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id BBF83E0454;
	Tue, 24 Feb 2009 16:36:37 +0000 (UTC)
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188])
	by pigeon.gentoo.org (Postfix) with ESMTP id 7CF80E0454
	for <gentoo-dev@lists.gentoo.org>; Tue, 24 Feb 2009 16:36:37 +0000 (UTC)
Received: by nf-out-0910.google.com with SMTP id d3so608085nfc.26
        for <gentoo-dev@lists.gentoo.org>; Tue, 24 Feb 2009 08:36:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:sender:received:in-reply-to
         :references:date:x-google-sender-auth:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=1G0sP5G7K3ITxBl9uLCAc9Otwt52zXG5MsGas5LJfC8=;
        b=OWarF8+Yod2eH4Rrqq+h9Bk/25S2kVK6HSa27Z2pbV48zs6pQ6v98cP3yMkGcJG0Y0
         +t7RATQlZC5y8gBCDNE/pa/mlxYOoIX9o0LCQZ5w9BYuaUa+ZNmDsjvfH7HB4m9qSi7/
         fx3sBslN0npN3WsaP5j3ESjTdA0ScoLigQN9k=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=BB86oGfTq/6My4lkpDGmlksMarEIBO3UIPoL1Esa6SvHZiA9WNvxjaF2xGKZFxgzdQ
         fYNs4hQRO8lCr7DuVmQOmS6NCXzhT9o+2OinswdyLx1tHowlNS5gX0GNPmOzY9AtuBIG
         p3aYqcB4rrlvznmRE/2pFEublZ9X/pGiIoR6Y=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Sender: nirbheek.chauhan@gmail.com
Received: by 10.110.39.20 with SMTP id m20mr495433tim.37.1235492979435; Tue, 
	24 Feb 2009 08:29:39 -0800 (PST)
In-Reply-To: <20090224155654.602f6c88@snowcone>
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>
Date: Tue, 24 Feb 2009 21:59:39 +0530
X-Google-Sender-Auth: 607e57806c30d434
Message-ID: <8b4c83ad0902240829k2ee96493hb6c1fae5dcc7d04e@mail.gmail.com>
Subject: Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: 
	Preliminary Meeting-Topics for 12 February 2009)
From: Nirbheek Chauhan <nirbheek@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Archives-Salt: ae568c4a-bb26-437a-bede-664fc5ebc6bb
X-Archives-Hash: 8658a917847507e52fafaac79f679f10

On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> ...and it means we can't change name or version rules.
>

And has such a case come to light recently where it was *essential* to
do so? Why solve problems that don't exist?

> ...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.
>

This is a valid cause. Perhaps the only valid cause.

> ...and it means we can't make arbitrary format changes.
>

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

> 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.
>

That's a documentation problem.


-- 
~Nirbheek Chauhan