From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11683 invoked from network); 2 Jul 2004 12:43:11 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 2 Jul 2004 12:43:11 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BgNNm-0007cB-Qv for arch-gentoo-dev@lists.gentoo.org; Fri, 02 Jul 2004 12:43:10 +0000 Received: (qmail 10957 invoked by uid 89); 2 Jul 2004 12:43:10 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 28865 invoked from network); 2 Jul 2004 12:43:10 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <43062.205.241.48.33.1088734649.squirrel@spidermail.richmond.edu> References: <40E4B84B.1040501@scms.waikato.ac.nz> <43062.205.241.48.33.1088734649.squirrel@spidermail.richmond.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-V3w36wZgwRYOIGQ5wHgq" Organization: Gentoo Linux Message-Id: <1088772514.16422.39.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 02 Jul 2004 08:48:35 -0400 Subject: Re: [gentoo-dev] Policy for retirement of old gentoo 'versions' X-Archives-Salt: be7c155c-a291-4886-b0f3-f4116cfcc6cc X-Archives-Hash: 6471f6a2cee42b4fe230873480c0712a --=-V3w36wZgwRYOIGQ5wHgq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-07-01 at 22:17, Donnie Berkholz wrote: > Barry Shaw said: > > Is there any policy/ideas/consensus among developers about how long a > > particular "version" will remain supported in portage? If not, it migh= t > > be a useful idea to set sunset dates for particular "versions" of gento= o > > (as I doubt they are all going to be supported indefinitely). If there > > is a clear end date, it prevents anyone being caught out unexpectedly. >=20 > I generally keep a minimum of two ebuilds in, so testing for a newly > introduced problem is easier. If I put out seven ebuilds in two weeks for > some ungodly reason, I don't expect to be maintaining some sort of minimu= m > lifetime for each ebuild -- just the newest two will stick around. >=20 > We have no policy stating a minimum support lifetime for any given versio= n > right now (AFAIK, of course), despite a push for it amidst emphasis for > Gentoo in the enterprise. As Donnie said, there is no policy laid out. In general, I will keep 2 versions in portage. Usually it is a stable version, and a testing version. Depending on the ebuild, I will leave more versions. For example, look at PXES or VMware Workstation. PXES is something that would be in use and probably not easily upgraded for everyone, so I have left every stable version in portage since I added the package. VMware Workstation is a licensed product, so I leave one version per license in the tree (3.x and 4.x). There are currently 2 4.x ebuilds simply because one is still in testing. Then you have packages like gcc/glibc, which usually stay in the tree for much, much longer. With an enterprise version of Gentoo, there will need to be much more help in maintaining certain packages, simply because patches will need to be back-ported to older versions and other such headaches that most other distributions must deal with. Right now, we simply don't have the manpower to keep up with such things, which is why we do not make things version dependent, where possible. --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-V3w36wZgwRYOIGQ5wHgq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA5VmikT4lNIS36YERAtayAJ9lRrttCvdEwIQW1knOfmgcDZXgngCgiBJt q7MRSKngFl7WSBZv8cX/+qg= =/aVh -----END PGP SIGNATURE----- --=-V3w36wZgwRYOIGQ5wHgq--