From owner-cvs-src@FreeBSD.ORG Thu Mar 10 18:31:17 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFBB816A4CE; Thu, 10 Mar 2005 18:31:16 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85E9643D4C; Thu, 10 Mar 2005 18:31:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j2AIVCiq005670; Thu, 10 Mar 2005 10:31:12 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j2AIVCa5005667; Thu, 10 Mar 2005 10:31:12 -0800 Date: Thu, 10 Mar 2005 10:31:12 -0800 From: Brooks Davis To: Paul Richards Message-ID: <20050310183112.GA4244@odin.ac.hmc.edu> References: <422E407B.4080507@portaone.com> <86k6oht386.fsf@xps.des.no> <422F087F.9030906@portaone.com> <20050309.085035.129356491.imp@bsdimp.com> <422F6703.70409@portaone.com> <20050310161607.GO98930@myrddin.originative.co.uk> <20050310165510.GE993@green.homeunix.org> <20050310172050.GR98930@myrddin.originative.co.uk> <20050310173645.GB25556@odin.ac.hmc.edu> <20050310181903.GU98930@myrddin.originative.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <20050310181903.GU98930@myrddin.originative.co.uk> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu X-Mailman-Approved-At: Fri, 11 Mar 2005 12:58:42 +0000 cc: Brian Fundakowski Feldman cc: Maxim Sobolev cc: src-committers@FreeBSD.org cc: Brooks Davis cc: cvs-src@FreeBSD.org cc: alfred@FreeBSD.org cc: cvs-all@FreeBSD.org cc: des@des.no cc: "M. Warner Losh" Subject: Re: cvs commit: src/sys/compat/linux linux_socket.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 18:31:17 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 10, 2005 at 06:19:04PM +0000, Paul Richards wrote: > On Thu, Mar 10, 2005 at 09:36:46AM -0800, Brooks Davis wrote: > > On Thu, Mar 10, 2005 at 05:20:50PM +0000, Paul Richards wrote: > > > On Thu, Mar 10, 2005 at 11:55:10AM -0500, Brian Fundakowski Feldman w= rote: > > > >=20 > > > > How is this even a problem? The company targets 5.3-RELEASE, perio= d, > > > > for all of 5.x. They do not need to upgrade their build computer to > > > > anything past RELENG_5_3 even in the face of security issues. > > >=20 > > > That really irritating bug that causes their development tools to > > > crash is fixed in 5.5. Clearly they'll want to run with that later > > > version. > >=20 > > Then they should tell their customers that they only support 5.5 or they > > should routinly test on 5.3 to make sure that keeps working. For that >=20 > That's the crux of FreeBSD's problem really. We can't tell the > commercial world to change the way they work to suit what we want > to do. If we want them to take FreeBSD seriously we have to fit > with the expectations they have. >=20 > > matter, in the case we are discussing, as long as they don't use the new > > flags they would not have any problems and if they failed to test on the > > old version they claimed to support that's their problem. >=20 > Across a stable branch I think it's unrealistic to expect commercial > developers to keep track of all these nuances. These are the sorts > of development overheads that make costs prohibitive and thereby > rule out support for particular platforms. If the company doesn't test their software on all the releases they claim to support or track changes between, how can they possibly expect it to work? Even making the assumption that no new features were added, how can they be sure they aren't using a feature that caused kernel panics in the previous release? As far as I can tell, there is no difference between adding a feature and fixing a bug that prevented a feature from working before. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMJJvXY6L6fI4GtQRAiPuAJ0eOxvXCLVD2TdZvTBifQcvOo6ePACg2V1T Omgqqvrec1GJpYRrB83wWM4= =Rg13 -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o--