From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24511 invoked from network); 9 Aug 2004 07:44:47 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 9 Aug 2004 07:44:47 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Bu4pq-0000Jb-PB for arch-gentoo-dev@lists.gentoo.org; Mon, 09 Aug 2004 07:44:46 +0000 Received: (qmail 14369 invoked by uid 89); 9 Aug 2004 07:44:38 +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 25563 invoked from network); 9 Aug 2004 07:44:38 +0000 Message-ID: <41172B3B.80007@scms.waikato.ac.nz> Date: Mon, 09 Aug 2004 19:43:55 +1200 From: Barry Shaw User-Agent: Mozilla Thunderbird 0.5 (X11/20040303) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org References: <20040808185144.GB29077@mail.lieber.org> In-Reply-To: <20040808185144.GB29077@mail.lieber.org> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] GLEP 19, reloaded (again) X-Archives-Salt: 575c794b-39d5-4261-8c9d-82d265b1acac X-Archives-Hash: f12b91cf7b2f7ae8a4f7021ab8faa538 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kurt Lieber wrote: | 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. | My main concern here is that if you've got a core server, which typically has lifetime of 3 to 4 years, you don't want to be reinstalling it every year (in many cases you can't). That said, I agree that its unlikely there are resources to maintain a tree for years on end. As a compromise, if some consideration was given to easing migration, that would be suitable. Given the fact that servers have a very minimal level of software on them anyway, its probably not too much of a big deal. | | 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. | I like this idea. That way if the end user doesn't want to upgrade, the original ebuild stays in portage and they can stick with that. Backporting has been mentioned in Greg k-h's post and I think thats something we want to stay away from. Ebuild maintainers may not have the programming skill necessary to backport fixes from one version of the software to another. The upstream maintainers are the experts in that respect and thats where that decision should stay. In my experience once the upstream maintainer stops maintaining a certain version of the software, migration to the new version is necessary anyway. The other downside to backporting is that it causes tonnes of false positives if you do any proactive network scanning. Not a major really, but its one of my pet hates 8) | 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) | These all sound like good alterations, keeping the GLEP focussed is a sensible idea. Baz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBFys7JvZkjpKMF2wRAutzAJ9pyJb/0VHtvuEOE3ggv2CIMpOGZACfZ2Cm sjiNxtYa8Q1HB+RKlZv9RzA= =630p -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list