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 1LQ2s2-0003BS-SL for garchives@archives.gentoo.org; Thu, 22 Jan 2009 16:57:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 62939E04BA; Thu, 22 Jan 2009 16:56:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 193C3E04BA for ; Thu, 22 Jan 2009 16:56:25 +0000 (UTC) Received: from gentoo.org (xray.science.oregonstate.edu [128.193.220.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 0BCD36484F for ; Thu, 22 Jan 2009 16:56:24 +0000 (UTC) Date: Thu, 22 Jan 2009 08:56:23 -0800 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22 Message-ID: <20090122165623.GA20446@comet> References: <20090121233526.GA15870@comet> <4977E7EC.8070007@gentoo.org> <20090122033805.GA9101@hermes> <4977F1B5.3080608@gentoo.org> <20090122161134.7c27ed3e@snowcone> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20090122161134.7c27ed3e@snowcone> User-Agent: Mutt/1.5.18 (2008-05-17) X-Archives-Salt: 226b610a-dc13-4dc6-b37e-eca5ef9068d0 X-Archives-Hash: 7d70eca34cfc519c44a0ea3c49ab835c --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 16:11 Thu 22 Jan , Ciaran McCreesh wrote: > On Wed, 21 Jan 2009 22:10:29 -0600 > Jeremy Olexa wrote: > > I think the spec should just be upgraded because it isn't exactly=20 > > obvious to the casual dev what is a 3.0 feature vs 3.1, etc. We > > already have 3.1 features in the tree, I'm not sure where the red > > tape is here. >=20 > The problem is, if the tree uses 3.1 and you don't have 3.1, it's a > massive pain in the ass to upgrade. We waited a loooong time between > 3.0 going stable and allowing it in the tree because of that. >=20 > Ideally we'd say "no using 3.1 features unless EAPI=3D3", but that would > be messy with eclasses even if developers did know that +=3D is a 3.1 > feature... Can this be fixed by adding bash dependencies to things using new=20 features? As long as we keep them out of the build path of bash, things=20 ought to work. Then we could add a repoman check for new features, if we=20 wanted. --=20 Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkl4pTcACgkQXVaO67S1rtuBMACfeVAJ4xFc6M6WqYjQFgz4A/7L wI0AoL4v7uSUrvc9Bx2mZMOpxq8H34zN =VGmN -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR--