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 1MEW4S-0001LK-9X for garchives@archives.gentoo.org; Wed, 10 Jun 2009 22:15:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A8BABE0357; Wed, 10 Jun 2009 22:14:58 +0000 (UTC) Received: from smarthost03.mail.zen.net.uk (smarthost03.mail.zen.net.uk [212.23.3.142]) by pigeon.gentoo.org (Postfix) with ESMTP id 7009CE0357 for ; Wed, 10 Jun 2009 22:14:58 +0000 (UTC) Received: from [62.3.120.141] (helo=NeddySeagoon) by smarthost03.mail.zen.net.uk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MEW4P-0000PP-PQ for gentoo-dev@lists.gentoo.org; Wed, 10 Jun 2009 22:14:57 +0000 Date: Wed, 10 Jun 2009 23:14:48 +0100 From: Roy Bamford Subject: Re: [gentoo-dev] Gentoo Council Reminder for June 11 To: gentoo-dev@lists.gentoo.org In-Reply-To: <1244668909.6190.23.camel@homer.ob.libexec.de> (from dertobi123@gentoo.org on Wed Jun 10 22:21:49 2009) X-Mailer: Balsa 2.4.0 Message-Id: <1244672097.3388.1@NeddySeagoon> 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=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Originating-Smarthost03-IP: [62.3.120.141] X-Archives-Salt: 1a9fc48a-40fa-449f-8601-49a103826027 X-Archives-Hash: b60ce781395a7b5e9c3939f000a88c81 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009.06.10 22:21, Tobias Scherbaum wrote: [snip] > The main "problem" is that there is no deployment process for newer > EAPIs specified right now. In the past we had something like "there > must be two releases (stage sets) including a Portage version=20 > supporting new features" before people were allowed to use new=20 > features in tree. We had a timeframe of something about a half year=20 > between introduction of new features and usage of them. At least in=20 > theory. >=20 > While having such a longer timeframe would make the deployment of new > EAPIs somewhat easier (especially the special cases when newer > versions of a package were migrated to a shiny new EAPI which isn't=20 > supported by a stable Portage yet and there's a need for quick=20 > versions bump due to security bugs) I think something inbetween that=20 > old process and the > currently used one would be useful. For example something like: New > EAPIs can be used in tree once a Portage version supporting that > specific EPAI has been marked as stable plus a transition period of - > say - 4 weeks after the Portage version has been made stable on the > first architecture. What about the case where the new EAPI breaks backwards compatibility=20 with existing package managers, as would be the case with glep 55? Its quite true that such changes can be introduced after a wait and=20 only upset late adoptors. By implementing the key feature of glep 55,=20 which is making the EAPI known to the PM without sourcing the ebuild, we would only need one last wait to introduce new features in this=20 way in later EAPIs.PMs would then know the EAPI in advance and ignore=20 ebuilds using EAPIs they don't understand. [snip] >=20 > Tobias >=20 >=20 - --=20 Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkowMGEACgkQTE4/y7nJvaswcgCfUa5dKLY8YYMyL7FjhIcNVXJg pO8An33Z2+1lm2jzkh9ciANzOhH+PqXv =3DyiKg -----END PGP SIGNATURE-----