> Date: Sun, 20 Jul 2008 14:22:09 +1000 > From: Edwin Groothuis <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > On Sat, Jul 19, 2008 at 09:36:38PM -0600, Brett Glass wrote: > > At 09:28 PM 7/19/2008, Subhro wrote: > > > > >You need to understand the release engineering process of FreeeBSD. > > > > I've been watching it (and testing release candidates) since 2.x, so > > I think I may possibly have some understanding of it by now. ;-) > > > > >The release edition is essential created from the stabe edition. 7.1R > > >would not be something new which is *not* present on 7-STABLE today. > > > > Mostly true. But the new release would undergo extensive testing, and > > changes which were "not ready for prime time" would be rolled back or > > made solid. I've had enough trouble with some recent snapshots of > > -STABLE that I'd rather install a release that's been thoroughly > > tested... preferably with the latest ports. That's why I'm asking > > about the likely actual release date of 7.1. > > The best thing a looking glass can come up with is: > > http://www.freebsd.org/releng/#schedule > > But that unless an announcement that as much worth as the lifetime > of the electrons hitting the back of your eyes.
I think we might have a communications issue. If I am wrong, sorry for the waste of bandwidth, First, 7.1 will not be out before Black Hat where the details of the vulnerability will be discussed publicly, so scratch that. Second, RELENG_7_0 has the patch plus two other security patches. IT IS NOT STABLE! It is 7.0 with exactly three important security patches and nothing else. While I find stable to be more stable and generally far better tested than release versions, I understand th preference many have for release versions. You have three options: 1. Upgrade to STABLE 2. Apply the patch to your existing system 3. Upgrade to RELENG_7_0 Of these, 2 is generally the easiest. 3 is probably the closest you can get to what you want, but pulls in two other security patches (which you probably should have installed, anyway) and 1 is probably the best approach in terms of system stability, but it does make a great many changes and it is probably not the best choice for a production environment where careful testing would be needed before deployment. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
pgpnKTveZmtYI.pgp
Description: PGP signature