From owner-freebsd-stable@FreeBSD.ORG Wed Jun 11 18:22:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D41281065675 for ; Wed, 11 Jun 2008 18:22:36 +0000 (UTC) (envelope-from prvs=pschmehl_lists=041eb2bf1@tx.rr.com) Received: from ip-relay-002.utdallas.edu (ip-relay-002.utdallas.edu [129.110.20.112]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC998FC1E for ; Wed, 11 Jun 2008 18:22:36 +0000 (UTC) (envelope-from prvs=pschmehl_lists=041eb2bf1@tx.rr.com) X-IronPort-AV: E=Sophos;i="4.27,625,1204524000"; d="scan'208";a="1441938" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-002.utdallas.edu with ESMTP; 11 Jun 2008 12:54:02 -0500 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id 4A6BD23DEA; Wed, 11 Jun 2008 12:54:02 -0500 (CDT) Date: Wed, 11 Jun 2008 12:54:02 -0500 From: Paul Schmehl To: freebsd-stable@freebsd.org Message-ID: <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> In-Reply-To: <20080611165009.O40102@fledge.watson.org> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> X-Mailer: Mulberry/4.0.6 (Linux/x86) X-Munged-Reply-To: Figure it out MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: mh@kernel32.de Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2008 18:22:36 -0000 --On Wednesday, June 11, 2008 16:54:02 +0100 Robert Watson wrote: > > On Wed, 11 Jun 2008, Andy Kosela wrote: > >> Redhat/CentOS is more reliable here as backports involves both security and >> bug fixes, plus even new hardware enhancements. > > In the FreeBSD environment, we call the place that gets a blend of security > and bug fixes, plus new minor feature and driver enhancements "-STABLE", and > the releases that pick up these changes "point releases". They happen more > requently and with less risk than major releases, but still see enough > development to represent functional improvements. > > I guess here's my concern: we offer a spectrum of choice for "I want the most > bleeding edge" to "I want no feature changes, just security fixes", and > several points in between. We can argue about the exact placement of this > points, but the reality is that the balance we have today seems to work well > for many developers and users, and reflects a fairly carefully planned use of > the available revision control and distribution technology. > > The place for volunteers to come in is where they see an obvious niche for > improvement -- for example, a few years ago this guy named Colin Percival > turned up with a binary update system. After a couple of years of > enhancement, breaking it in, etc, it's now a standard tool for maintaining > FreeBSD systems, and he's our security officer. Similar opportunities exist > for offering easier updates to packages, etc, but require people who have a > clear need and the technical ability to do the work to turn up and do it. > >From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat "port" is vulnerable or not, because RedHat uses their own proprietary versioning system to define "where" a particular "port" is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer.