Date: Thu, 05 Jun 2008 12:46:31 -0400 From: Chris Marlatt <cmarlatt@rxsec.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: challenge: end of life for 6.2 is premature with buggy 6.3 Message-ID: <48481867.3010809@rxsec.com> In-Reply-To: <g29478$6k8$1@ger.gmane.org> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <4846E14C.709@FreeBSD.org> <AC78CAC0-BA7C-4A20-9BEE-E7E37FD225E7@netconsonance.com> <48472CCF.8080101@FreeBSD.org> <4847EF62.1070709@rxsec.com> <4847F814.10409@FreeBSD.org> <4847FB1D.1050400@rxsec.com> <4847FFDE.8000209@FreeBSD.org> <48480473.3010009@rxsec.com> <g29478$6k8$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras wrote: > Chris Marlatt wrote: > >> The option provided seems like a fairly good compromise to both >> interests. Pick 6.3 (or anything the release team wishes) to support for >> a longer period of time. Keep all other releases to 12 month support and >> continue doing what I believe is some fairly incredible work. I really >> don't see the downside to it. If anything it should reduce the work load >> for the team and let them focus on making considerable progress. >> Especially considering Ken Smith's recent post regarding future release >> schedules. > > This is already being done: 6.1 was a "long term support" release. > > The topic comes about pretty often. I think it's because people are > still impressed / spoiled by 4.x and wish they had a stable operating > system that's supported for 6+ years (like 4.x had been). I even heard Spoiled is probably a good word for it. But you have to admit it's extremely useful to the user base to have such support. This was quite evident by the apposition to discontinue the 4.x branch. > commercial / embedded companies saying they would use FreeBSD if only > they had a 5+ years run off a branch (which is comparable to what Debian > has, if you allow 3.0 and 3.1 to be "similar enough"). > > But all is not so bad: consider for example 7.x: 7.0 was released > 2008/02, and from Ken's schedule the last release, 7.4 will be released > 2009/12, with probable support for maybe 1-2 more years which makes the > whole 7.x generation of the OS officialy supported for 3, maybe 4 years, > which is a lot in fast technology-changing world. I think you're missing the point. Whereas it is indeed helpful to have the major release supported for that duration of time. The concern was over the minor release support. For instance if 7.0 is only supported for 12 months it doesn't really matter if 7.x is support for 48. You still need to upgrade and deal with any potential problems 7.1 or 7.2 induces if you wish to continue having "vendor supplied" security fixes. However using the 7.x tree as an example is problem not the best. 7.x, at least from what I've perceived, is a fairly active development branch. The 6.2 to 6.3 change is somewhat a better example but still not perfect. > > I know long term support is not doable with the resources the project > currently has, but I've been toying with the idea that maybe there's an > opportunity for commercial development here - a company that would > backport security fixes and important driver fixes for ($$$ * > (N-YEAR_OF_LAST_RELEASE)) more years or something. > > Regards, Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48481867.3010809>