Date: Wed, 11 Jun 2008 14:36:30 +0200 From: "Andy Kosela" <andy.kosela@gmail.com> To: freebsd-stable@freebsd.org Cc: rwatson@freebsd.org, lists@lozenetz.org, mh@kernel32.de Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 Message-ID: <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> In-Reply-To: <b97c11a8a910057f0ea95f737791d968@localhost> References: <484FA07E.60103@lozenetz.org> <b97c11a8a910057f0ea95f737791d968@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert, Thank you for your insights. I think that this agreement between users and developers does occur. The proper balance between rapid development vs long term stability is the platform through which such agreement can be achieved. It's up to the Core Team to reasonably steer the Project in such a way as to achieve the greatest results. FreeBSD has always been focused on creating simple, stable and reliable operating system for system administrators and let's keep it that way. Longer term support for -RELEASE gives many companies a stable platform to develop and maintain their infrastructure. I think 5 years support for major FreeBSD release (like major 6 or 7) would be really perfect for many of us. On Wed, Jun 11, 2008 at 1:26 PM, Marian Hettwer <mh@kernel32.de> wrote: > But there is a way around. As soon as you have several FreeBSD boxes, I'd > advise you to install your own FreeBSD box for packages building. > So if you need to update your php installations, go to your build box > (which has the very same versions of programs installed as your production > boxes), update your ports tree and do a "make package" of your new php > port. > If the new php package works fine on your build box, roll it out via > "pkg_add -r $NEWPHPTHINGY" and off you go. I think Anton raised a valid and reasonable point here by analyzing my previous statements. Every data center environment test the upgrade process before deploying it on production machines, but my point circulated around the whole different theme. Backporting Backporting security and bug fixes to *STABLE* versions of ports would definetly render the whole ports framework infrastructure more solid and trustworthy for organizations that need mission critical stable and reliable environment to work in. Creating -SECURITY branch of ports tree with support *just* for common server applications like apache, postfix, mysql or vsftpd (definetly not for all available ports) would very well encourage more companies now stuck with the only alternative (redhat/centos or debian) to trust this ports tree branch in deploying their applications which very often needs specific versions of the software to run properly. Right now it's sometimes very risky to jump to the latest available upstream version as it very often breaks compatibility with older versions. I've been toying with the idea to create such -SECURITY branch, at least just for ports I use extensively. I'm not aware of no such project (open source, commercial) that is doing that. I'm curious how many people out there would be also interested in such an idea. > If you take a close look onto how the debian project is backporting > security fixes you would probably agree that pretty often it's more > desireable to jump to a newer version of that software than instead just > security fixing it. > Examples needed? > MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got > security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in > Debian but not a stable one, because important bugfixes are missing. > I'd rather upgrade to the latest MySQL 4.1.xx instead. > And of course, do your testing before jumping version numbers. Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. -- Andy Kosela ora et labora
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3cc535c80806110536w1c8af6efq8d5470ce6de8cb38>