From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24383 invoked from network); 21 Jul 2004 21:39:45 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 21:39:45 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnOoS-00078c-30 for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 21:39:44 +0000 Received: (qmail 19045 invoked by uid 89); 21 Jul 2004 21:39:43 +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 11768 invoked from network); 21 Jul 2004 21:39:42 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <1090444335.372.18.camel@montreal> References: <20040720131405.GW18023@mail.lieber.org> <200407201643.25486.absinthe@gentoo.org> <1090440033.11369.111.camel@localhost> <1090444335.372.18.camel@montreal> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5+QH23c3j5G4UOQeQ9zF" Organization: Gentoo Linux Message-Id: <1090445997.19552.156.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 17:39:57 -0400 Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: af72072b-5cc6-4cc7-a1ca-573431f85ab4 X-Archives-Hash: ca95ae465dfcb96125e48c24c9365078 --=-5+QH23c3j5G4UOQeQ9zF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-07-21 at 17:12, Olivier Crete wrote: > I like the idea of a separate tree.. But if it really rarely changes, > rsync is just overkill and will overburden our mirrors.. Lets just make > it a tarball and put the enhancements in a rsync'ed overlay. Rsync is > for stuff that changes... That works for me. I was simply trying to propose a way to do it with the least amount of changes for the users. Perhaps have the main tarball delivered by rsync so a version switch is still transparent? > This overlays should probably each have their own cvs module (or all be > directories under the same module, I dont really care... Where all > package maintainers would have access.. And then we can mark them stable > using the same kind of procedures we currently use for GLSAs... >=20 > Also, the problem with maintaining older versions is that we need to > have at least one machine available for each version where the concerned > devs can test security updates.. Ok, maybe at least one per > architectures using chroots... but its still a lot of infrastructure.. > That's why reducing the number of stable releases to maybe even just one > a year might be a good idea. I'm not opposed to that. I think I would prefer 2, simply to reduce the amount changed between releases, making it easier for users to upgrade.=20 Switching to 2 releases per year with a 4 release retention puts us at 2 years of support in the -release trees. Switching to 1 year release cycles puts us out to 4 years. An awful lot can change in 4 years in the Linux world. I'm not sure we would possibly be able to keep up with such a long-reaching goal. Personally, I would say we try to move on this by 2005.0 and see what happens, without changing release schedules and only supporting 4 releases. This would carry us through 2005.X and into 2006.X, where we could make adjustments to the release cycle if we deem it necessary. --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-5+QH23c3j5G4UOQeQ9zF 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) iD8DBQBA/uKtkT4lNIS36YERAhn1AJ0d5ev5oyzf1/zktoQsr0Cmwb2ukwCgw15B PH1G0xzm8eCrEvTdzONa9iU= =isCu -----END PGP SIGNATURE----- --=-5+QH23c3j5G4UOQeQ9zF--