Date: Wed, 11 Jun 2008 12:54:02 -0500 From: Paul Schmehl <pschmehl_lists@tx.rr.com> To: freebsd-stable@freebsd.org Cc: mh@kernel32.de Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 Message-ID: <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> In-Reply-To: <20080611165009.O40102@fledge.watson.org> References: <484FA07E.60103@lozenetz.org> <b97c11a8a910057f0ea95f737791d968@localhost> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Wednesday, June 11, 2008 16:54:02 +0100 Robert Watson <rwatson@FreeBSD.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E2C3BF30A4BC75D1D837828>