From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14050 invoked from network); 21 Jul 2004 19:55:31 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 19:55:31 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnNBa-00082e-2b for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 19:55:30 +0000 Received: (qmail 14500 invoked by uid 89); 21 Jul 2004 19:55:25 +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 30634 invoked from network); 21 Jul 2004 19:55:24 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <40FDCD20.6080302@scms.waikato.ac.nz> References: <20040720131405.GW18023@mail.lieber.org> <40FDCD20.6080302@scms.waikato.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GG6DF+d8WRH3MrhY7ddX" Organization: Gentoo Linux Message-Id: <1090441261.19552.124.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 16:21:01 -0400 Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: 37c2123a-92c6-4576-94b4-c8d8e1dda932 X-Archives-Hash: 471f47e61a9ffdd25006fae600f82c77 --=-GG6DF+d8WRH3MrhY7ddX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-07-20 at 21:55, Barry Shaw wrote: > It might be worth considering instead a model where a snapshot is taken > then only security patches are applied, with the exception that should a > particular version of an application become depreciated, it can then > also be upgraded (provided the upgraded version is also considered stable= ). I would have no problem with this, provided it was the up-front decision and we stuck to it. It would still fit in with my (rather lengthy) proposal, and would reduce the developer overhead significantly. > This would enable snapshots to last for a longer period (I think four a > year is going to be too much work), it prevents any requirement for > backporting (which I think is a bad idea as it makes ebuild maintainers > into application maintainers) and it would also make the maintenence of > older snapshots more viable as there would be less work to do in general. I think 2 a year with a 2 year retention (4 releases) would be the sweet spot. Nothing keeps users from running older releases, just we don't support them officially any more. > Some of the current discussion on the length of time snapshots are > maintained is concerning as production servers, in my experience, remain > in the same state for years - a one year maintenence period is not long > enough (it would be for workstations however as these are easier to take > out of service for an hour or so and upgrade). What about Red Hat (think RHL, not RHEL)? They only ever supported I believe 2 releases back and had a release approximately every six months. At the same time, there are many servers out there that still run 7.3 and even 6.2 and work perfectly fine. Depending on their function, they may be completely secure, also. It is not that difficult to write an ebuild. Nothing is stopping a user from importing an ebuild from the -current tree or any other -release tree into their overlay for an upgrade. We simply have to put a limit on how far back we support, especially as we are a community-based distribution. > In reality, if a application on a production server reaches a state > where it is unmaintained in favour of a newer version, then its likely > that the admins would upgrade the application to the supported version. > ~ Most responsible program maintainers provide upgrade paths anyways, so > as long non security related package upgrade wasn't forced on > subscribers to the stable tree, it shouldn't be too bad. At the least > if such a change could be signalled, people would be prepared. My thinking exactly. With frozen package versions in the -release trees, a company could evaluate whether their software operated as expected on the new release. Also, since we would be providing a simple upgrade path, it would ease the workload on administrators using "Enterprise Gentoo". > I guess what I'm describing isn't strictly an enterprise gentoo (which I > don't think the community has the resources to support), more of a > slowed down version of the main portage tree. In my experience > maintaining a couple of hundred of gentoo machines centrally, its the > rapid pace of change in the main tree that causes problems. We only > only upgrade packages for security reasons, but whenever we do this, we > are forced to upgrade a multitude of other packages because they've > dropped out of portage. If we only had to upgrade packages for security > and depreciation reasons it would make for a much more stable > environment for the end users (which is what we're after ultimately) and > ~ it would make maintenence more manageable. I agree that there is no real need for an Enterprise Gentoo, but rather fixed releases. --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-GG6DF+d8WRH3MrhY7ddX 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/tAtkT4lNIS36YERAsnzAJ0QfKyXT8O+nIWP2MFvEwFnTddiswCfeuGd l2a+wSfPFjiBjWXW7ZsM32Y= =awfg -----END PGP SIGNATURE----- --=-GG6DF+d8WRH3MrhY7ddX--