From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 953 invoked from network); 10 Aug 2004 14:12:15 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 10 Aug 2004 14:12:15 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BuXMK-00062A-LT for arch-gentoo-dev@lists.gentoo.org; Tue, 10 Aug 2004 14:12:13 +0000 Received: (qmail 13433 invoked by uid 89); 10 Aug 2004 14:12:12 +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 13855 invoked from network); 10 Aug 2004 14:12:11 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <20040810132409.GG29077@mail.lieber.org> References: <20040808185144.GB29077@mail.lieber.org> <200408090104.50263.absinthe@gentoo.org> <20040809095214.GJ29077@mail.lieber.org> <1092061268.30233.18.camel@localhost> <20040810000107.GX29077@mail.lieber.org> <1092144188.21441.19.camel@localhost> <20040810132409.GG29077@mail.lieber.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rB53wX3kRG1z15I09rRP" Organization: Gentoo Linux Message-Id: <1092146131.21439.47.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 09:55:31 -0400 Subject: Re: [gentoo-dev] GLEP 19, reloaded (again) X-Archives-Salt: e8ef905c-86eb-4e24-82d9-8430e8636159 X-Archives-Hash: 40ea448554464d4cde05c3fbe8b32b4f --=-rB53wX3kRG1z15I09rRP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-08-10 at 09:24, Kurt Lieber wrote: > The release schedule for liveCDs/package sets is 4/year. We're talking > about an annual cycle here. At no point have I ever seen a cycle mentioned for the "stable" tree, until now. Also, I've stated in many threads before that -releng is more than willing to work with whomever to make changes to the release cycle to best serve the needs of our users. UNFORTUNATELY, it seems that people don't read most of the threads that go on here, so I have to repeat myself quite a bit to get this out to everyone interested... ;] > > So the idea is to create exactly *one* stable tree? How is this any > > different than just doing better with our current tree? Honestly, from > > what I've heard from our users, they want package stability (as in > > freeze) much more than anything else. This is *exactly* why I recommen= d > > tying the "stable" trees with the releases. I'm not sure I can > > understand how doing anything else really gives us anything other than > > adding more workload for the simple fact of adding workload. Having a > > "stable" tree that still moves, and only providing a single "stable" > > tree doesn't seem to be an improvement from what we have at all. >=20 > No -- we would have one tree for each release, but the difference is that > you're talking about using the tree to control versions and I'm talking > about using profiles to control versions. With the current proposal, the > *only* difference between the main rsync module and the "stable" module i= s > that the latter has the --delete option removed. This is to ensure ebuil= ds > remain in the tree for a predictable period of time. It has nothing to d= o > with package versioning. So we move no closer to our goal of providing a stable/frozen installation environment than to ensure ebuilds don't disappear from the tree? How is this really beneficial to our users? Is there a reason for completely separating the idea of a "stable" tree from our already established releases? Is there a reason why they cannot both be modified to work together and do what is best for our users, gives them the most choice, and gives them what they're actually asking for? --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-rB53wX3kRG1z15I09rRP 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) iD8DBQBBGNPTkT4lNIS36YERAkNOAJ9ChQ07iP1lUsSwInOBJgpnw9ZZMQCfdKpl vrlKA2jPGJ7pno8CLuHYCzk= =2rw/ -----END PGP SIGNATURE----- --=-rB53wX3kRG1z15I09rRP--