From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15893 invoked from network); 8 Aug 2004 18:49:42 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 8 Aug 2004 18:49:42 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Btsjl-00057n-C1 for arch-gentoo-dev@lists.gentoo.org; Sun, 08 Aug 2004 18:49:41 +0000 Received: (qmail 22484 invoked by uid 89); 8 Aug 2004 18:49:40 +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 18892 invoked from network); 8 Aug 2004 18:49:40 +0000 Date: Sun, 8 Aug 2004 18:51:44 +0000 From: Kurt Lieber To: gentoo-dev@lists.gentoo.org Message-ID: <20040808185144.GB29077@mail.lieber.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline X-GPG-Key: http://www.lieber.org/kurtl.pub.gpg User-Agent: Mutt/1.5.6i Subject: [gentoo-dev] GLEP 19, reloaded (again) X-Archives-Salt: 93f6ff11-f620-40d8-988a-7e847a2368d7 X-Archives-Hash: 69f7fe15df17fbc914d3d63e5026084f --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable OK, as msot of the other folks who attended LWE will attest, a stable portage tree was the number one most-requested/discussed feature at the booth. So, here's a stab at summarizing the other flame^Wthread and suggesting some next steps... First off, some folks tried to bolt on some features to the GLEP 19. Things such as XML-based ChangeLogs might be nice, but they're outside the scope of this GLEP. So, I'm ignoring them for purposes of this discussion. Second, there was some question about how often the tree would be updated. The GLEP doesn't really specify this, but I think once a year is a reasonable timeframe. Third, many folks want long-term support of these releases. I *don't* think this is viable and am not willing to personally sponsor this. A core component of this GLEP is that we will *not* be backporting security fixes. (at least not as a rule) We will be relying on the versions that the original authors provide except in very unusual circumstances. The reason for this is simple -- we don't have the resources to guarantee that we can backport things (and, more importantly, guarantee that they'll work right once backported) Suppporting a profile for four or more years almost guarantees you'll be doing a lot of backporting. I don't plan to incorporate long-term support as part of this GLEP. That might, however, be an excellent opportunity for commercial companies with greater finanial resources than us. =20 Fourth, the GLEP currently recommends use of a 'stable' keyword. A number of folks have suggested using a custom profile instead. This is less intrusive and doesn't require any changes to portage to make it work. It's also easier to maintain since everything is in one file. The main problem here is that all packages need to be explicitly listed in this file in order to be of any use. If we can get enough developer buy-in and maybe even add some repoman checks, this might be easier to manage... Finally, the current GLEP doesn't really address how to ensure a minimum life for all ebuilds in the tree. I'm open to suggestions on this, but the best idea I've heard so far is using a separate rsync module and removing the --delete option from the command used to populate it. So, at this point, I'm suggesting three changes to the GLEP: 1) specify annual updates for the stable tree 2) replacing the stable keywording stuff with stable profiling stuff 3) adding a separate rsync module for the stable portage tree (or one for each release of the stable portage tree) With that, comments/suggestions are welcome. Please keep in mind that this is a very focused GLEP designed to provide a stable tree and predictable expiration of ebuilds to our users. It is not intended to propose other far-reaching changes to Gentoo Linux. --kurt --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBFnZAJPpRNiftIEYRAr6UAKCPo8T8WOJt7mNT5dH34XHYog7EsACfQFsM zAwrVwWsUrHZYUmsn//0Szg= =NHQW -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M--