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 1LcDZz-0007IZ-80 for garchives@archives.gentoo.org; Wed, 25 Feb 2009 06:49:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2313FE031D; Wed, 25 Feb 2009 06:49:14 +0000 (UTC) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by pigeon.gentoo.org (Postfix) with ESMTP id CF624E031D for ; Wed, 25 Feb 2009 06:49:13 +0000 (UTC) Received: from epia.jer-c2.orkz.net (atwork-106.r-212.178.112.atwork.nl [212.178.112.106]) (authenticated bits=0) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n1P6n9nr088047 for ; Wed, 25 Feb 2009 07:49:09 +0100 (CET) (envelope-from jer@gentoo.org) Date: Wed, 25 Feb 2009 07:49:08 +0100 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Message-ID: <20090225074908.195330a5@epia.jer-c2.orkz.net> In-Reply-To: <49A472E3.1010204@gentoo.org> References: <49A472E3.1010204@gentoo.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.12.11; i686-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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by XS4ALL Virus Scanner X-Archives-Salt: 414cdec4-6263-446b-af44-57c62ee842b7 X-Archives-Hash: b5c886ac1cf052c617dcb5304b89ec6e On Wed, 25 Feb 2009 00:21:23 +0200 Petteri R=C3=A4ty wrote: > Let's try something new. I would like to get opinions [...] A multitude of leaves on every branch of the tree. That could be a multiple of the current tree size - maybe talk to infra about this. It's also a multitude of complexity - as an arch security liaison, I get to see how difficult it is already to figure out which revision to test and mark, and figuring out why a certain revision isn't ready yet is tantamount to figuring out what EAPI=3Dfoo actually means. As an ebuild developer I get to see how difficult it is to figure out which EAPI is ready enough to write ebuilds for - Changing filename extensions is to me like a Windows 95 way of opening a file and it doesn't at all tell me what I can and cannot put into that file. Either as an arch, or as ebuild dev pur sang, I don't care about EAPIs that much until I want to use a new feature - I don't want to maintain EAPI=3DN branches of testing and stabling systems to test stuff either before it's published or when it's time for stabilisation. Stamping EAPIs down in filename extensions is just another way to point out the cruft. As a bug wrangler, it doesn't solve current problems of stale overlays with too novel or too old ebuilds. To users, it doesn't matter at all - which seems to bring about the question of the use case everyone's clamouring for. What developers will benefit this at all, how large are the branches this will affect, how many developers will have to rewrite tools, and so on? Kind regards, jer