From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27540 invoked from network); 10 Aug 2004 21:03:55 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 10 Aug 2004 21:03:55 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Budmk-0007nS-Ul for arch-gentoo-dev@lists.gentoo.org; Tue, 10 Aug 2004 21:03:55 +0000 Received: (qmail 16564 invoked by uid 89); 10 Aug 2004 21:03:54 +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 64 invoked from network); 10 Aug 2004 21:03:54 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <200408102119.26115.chrb@gentoo.org> References: <20040808185144.GB29077@mail.lieber.org> <200408101333.31687.pauldv@gentoo.org> <200408101433.51555.absinthe@gentoo.org> <200408102119.26115.chrb@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oF5JdIsobOrRMGVnrX18" Organization: Gentoo Linux Message-Id: <1092173069.21439.138.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 17:24:30 -0400 Subject: Re: [gentoo-dev] GLEP 19, reloaded (again) X-Archives-Salt: 4967b14c-296c-46b9-82ff-bbfb3ddde33d X-Archives-Hash: 005203cdc266ed4b8b67ef590958eaca --=-oF5JdIsobOrRMGVnrX18 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-08-10 at 16:19, Chris Bainbridge wrote: > Ok I've been following this thread for a while and have a few observation= s and=20 > a cheeky proposal. Observations: >=20 > * I don't believe gentoo has many developers who are interested in suppor= ting=20 > "old" software. It just doesn't scratch the itch. Agreed. > * We don't have the resources to backport security fixes either. Upgradin= g is=20 > not an option for many enterprises, they want backports. Someone mentione= d=20 > grabbing fixes from other distros... fine, but what if the versions diffe= r? Fix it for the version in question. It's usually a lot easier to fix a broken patch than to discover and patch a problem yourself. > What about major non-security bug fixes? This hasn't been discussed. Personally, I think any fix that doesn't alter functionality (typo fixes, bug fixes) or add new features is fine. Some people will want security fixes and nothing else. > * A 1 year support cycle isn't long enough for enterprise users. We're not talking about commercial support here. Also, we aren't talking about providing *any* semblance of support. The idea is to get a tree out there, as that seems to be enough to satisfy a large number of people. Perhaps having the tree out there will bring forth more help. Perhaps it'll bring about an interested third party willing to offer commercial support. Perhaps it'll bring about nothing. No matter what the outcome, it doesn't cost us much in time, and it satisfies a good number of our users, so we should do it. > * Redhat has the resources to run enterprise support. They do backports a= nd=20 > bugfixes. For years. No argument here... They will fix whatever you want, provided you "show them the money", so to speak. > * Redhat is the standard for enterprise linux (if you want oracle, eda=20 > software etc.). Many companies don't even test on anything else. I have a= =20 > stack of commercial chip design software here, and all of it is redhat on= ly. I'll agree here, too. > So heres the cheeky proposal... make a "redhat" release. Follow redhats=20 > release cycle, and match their versions. Use their backported fixes.=20 > Commercial software will work. Bugs will be fixed. This is the power of o= pen=20 > source. Why? So users can have portage and the "commercial vendors" will still release their stuff in RPM only and expect the exact same libraries of the same versions to be installed with the same features as Red Hat.=20 Are you also wanting to get rid of USE flags? How about CFLAGS? To be able to ensure Red Hat compatibility, both of those would have to be standardized to be exactly like Red Hat's. This means CFLAGS would be what Red Hat uses and we would compile with the same ./configure options on each package. At that point, we're wasting an enormous amount of time trying to be Red Hat, and no time trying to make Gentoo better. --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-oF5JdIsobOrRMGVnrX18 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) iD8DBQBBGT0NkT4lNIS36YERAkWOAJ9uXrXZJchAIm8iCDxM4/iL/gYSoACglvbJ KuP20B6X8eukQRiyLE1KGyo= =2kkC -----END PGP SIGNATURE----- --=-oF5JdIsobOrRMGVnrX18--