From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M9fOR-00046G-QT for garchives@archives.gentoo.org; Thu, 28 May 2009 13:11:36 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 703B9E0464; Thu, 28 May 2009 13:11:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 34408E0464 for ; Thu, 28 May 2009 13:11:33 +0000 (UTC) Received: from [192.168.1.213] (74-92-132-138-WashingtonDC.hfc.comcastbusiness.net [74.92.132.138]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 9204A6423D for ; Thu, 28 May 2009 13:11:32 +0000 (UTC) Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28 From: Ferris McCormick To: gentoo-dev@lists.gentoo.org In-Reply-To: <1243428376.31661.38.camel@liasis.inforead.com> References: <1243364226.9837.34.camel@localhost> <1243428376.31661.38.camel@liasis.inforead.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-l2CN2r5pNFwiWFSTtffI" Organization: gentoo developer Date: Thu, 28 May 2009 13:11:30 +0000 Message-Id: <1243516290.31661.72.camel@liasis.inforead.com> 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 X-Mailer: Evolution 2.24.5 X-Archives-Salt: dbe88f17-eb48-46a6-8011-4d6968b8d79f X-Archives-Hash: ee3a3232389ac198030d2a3e4dcfbe7f --=-l2CN2r5pNFwiWFSTtffI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2009-05-27 at 12:46 +0000, Ferris McCormick wrote: > On Tue, 2009-05-26 at 20:57 +0200, Tiziano M=C3=BCller wrote: > > This is your friendly reminder! Same bat time (typically the 2nd & 4th > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ > > irc.freenode.net) ! > >=20 > > If you have something you'd wish for us to chat about, maybe even vote > > on, let us know! Simply reply to this e-mail for the whole Gentoo dev > > list to see. > >=20 > > For more info on the Gentoo Council, feel free to browse our homepage: > > http://www.gentoo.org/proj/en/council/ > >=20 > >=20 > > Following is the preliminary meeting agenda. First we'll have to fill > > the empty spot. After a short upgrade on EAPI-3 implementation we will > > discuss the removal of old eclasses, followed by our old friend GLEP 55= . > > If we still have time we can dive into the topic of general EAPI > > development. > >=20 >=20 > Because Piotr recently amended GLEP55 to provide some further > clarification and justification as well as to present a few alternatives > addressing some objections people have expressed, it seems to me that > the GLEP55 discussion should now go something like this: >=20 > 1. Approve the concept in principle (I think Piotr's examples > sufficiently show the need for something along the lines set out in the > revised GLEP); >=20 --- SNIP --- I did not intend to set off another religious war with this. I was merely expressing my own opinion in response to the request from Council. But it seems every time GLEP55 is mentioned, there is a cascade of emotional responses, but I don't see anything in GLEP55 worth any sort of emotional response, so consider this directed at council. If anyone has technical issues with it, please either make them as such and leave out the personal attacks. 1. For some reason, there were comments about the writing style used in GLEP55. Personally, I find it clear enough, and would expect that it would be revised once Council settles on whether to adopt the proposed solution or one of its alternatives. (That's why it's marked as a draft.) In my opinion, as it stands it clearly shows the necessity for it or its equivalent (one of the alternatives it mentions); 2. I said that no matter what we do, I think we need a new extension; 3. Personally, I prefer .eb (with eapi defined elsewhere) to .ebuild-, but I view that as more a matter of taste than a major technical matter; 4. Personally, I prefer ${PN}-${PVR}.eapi-.eb (or a syntactic equivalent); again, that is a matter of taste and performance; 5. As an alternative, I have no problems with ${PN}-${PVR}.eb and using #!eapi as the first line of the .eb[uild] file. In that case, I suppose you could even follow through and source a program called 'eapi', but that's a PM implementation issue outside the scope of the GLEP. The argument against this is performance hit, I guess, and on that I am not qualified to comment. 6. My remarks about -scm were merely meant to show that once you introduce the .eb extension, you can implement GLEP54 transparently in whatever manner excites you. As I said at the beginning, these are my personal preferences addressed to Council in response to their request. If others have preferences which differ, please take them up with me (I am open to persuasion), and please leave the emotion out of it. But I think GLEP55 adequately makes the case for it or one of the alternatives it mentions, so don't bother arguing with me on that matter. It's Council you need to convince, not me. Regards, Ferris --=20 Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) --=-l2CN2r5pNFwiWFSTtffI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEUEABECAAYFAkoejYIACgkQQa6M3+I///fjuwCYgxeBc9t0zbLcWcIz7NKhpZEc mACgx2pqN9UDSr0TPlCzqnz2s1DIq1c= =y/su -----END PGP SIGNATURE----- --=-l2CN2r5pNFwiWFSTtffI--