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 1M9IYJ-0008FK-6B for garchives@archives.gentoo.org; Wed, 27 May 2009 12:48:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7FBC3E062B; Wed, 27 May 2009 12:46:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3BC66E062B for ; Wed, 27 May 2009 12:46:19 +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 6D50B66313 for ; Wed, 27 May 2009 12:46:18 +0000 (UTC) Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28 From: Ferris McCormick To: gentoo-dev@lists.gentoo.org In-Reply-To: <1243364226.9837.34.camel@localhost> References: <1243364226.9837.34.camel@localhost> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-kPoihjM82c8wViKsiAjV" Organization: gentoo developer Date: Wed, 27 May 2009 12:46:16 +0000 Message-Id: <1243428376.31661.38.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: 8140d198-0675-4ef0-a084-23382f5de942 X-Archives-Hash: 7afb92ba6a148eaba005b192b4e79f3d --=-kPoihjM82c8wViKsiAjV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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: 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); 2. Choose one of the proposed solutions. For what it's worth, I favor the new extension (package.ebuild --> package.eb), and then I think something like ${PN}-${PVR}.eapi-${EAPI}.eb (or equivalent) is probably best. Here, ${PVR} is perhaps in a new version format. a. No introduced overhead; b. Current PMs will not even see it; c. I think there is an advantage for the users and developers to be able to see the required eapi immediately without having to read all the .eb (or .ebuild if you choose .ebuild-) files. 3. Approve the GLEP. I would do the first quickly in order to cut off all the continual noise on gentoo-dev@, and I really think the revised GLEP makes the case for it well enough. After that, it should no longer be a religious issue, and I optimistically would not expect step 2 to take long at all. I note that the .eapi-${EAPI} part could well be optional, in which case GLEP54 falls naturally into the new scheme as something like ${PN}-${PVR}-scm.eb >=20 > Approval/voting of new council member replacing Donnie Berkholz > --------------------------------------------------------------- >=20 > Unfortunately Donnie resigned as a member of the council (for > details please read his mail on the g-council ml). Next in line > are ulm and ssuominen. >=20 >=20 > EAPI 3: Short discussion of the progress > ---------------------------------------- >=20 > zmedico will provide an update on the progress of the implementation. Sho= rt > discussion of problems and implementation decisions if needed. >=20 >=20 > Removing old eclasses > --------------------- >=20 > Goal: Decide whether developers are allowed to remove eclasses. Problem: > Upgrading using portage with a version before 2.1.4 will fail since porta= ge > always used eclasses from the tree instead of the ones from environment.b= z2, > even though the environment fail has been generated. Portage 2.1.4 got st= abled > over a year ago. >=20 >=20 > Handling EAPI versioning in a forwards-compatible way > ----------------------------------------------------- >=20 > Goal: Discuss whether one of the alternatives given in GLEP 55 is appropr= iate > to solve the problem. Decide which one should be chosen. >=20 >=20 > Define EAPI development/deployment cycles > ----------------------------------------- >=20 > Goal: Start discussion about EAPI development/deployment. For example: > Collect problems of eapi introductions in the past, like reverting > ebuilds to former eapis to get them stable, not waiting for the pm > support a certain eapi before requesting stable keywords for ebuilds > using the new eapi, .... Collect problems of EAPI development like > feature-freeze, late feature removals (due to implementation problems). > Eventually develop a lightweight EAPI development model. >=20 >=20 > Cheers, > Tiziano Regards, Ferris --=20 Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) --=-kPoihjM82c8wViKsiAjV 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) iEYEABECAAYFAkodNhgACgkQQa6M3+I///eVjACfY5/6dOpP5q/K6gldhjLozCS8 rvcAn3jX05UluvvudYKnurS5IC6Sq3T7 =FyaN -----END PGP SIGNATURE----- --=-kPoihjM82c8wViKsiAjV--