Date: Tue, 21 Dec 2010 09:56:16 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: mdf@FreeBSD.org Cc: freebsd-arch@freebsd.org Subject: Re: Schedule for releases Message-ID: <8A01BB52-1A71-4185-9120-F36F0B6C160D@gmail.com> In-Reply-To: <AANLkTi=_mHDz3LZ1SAuCsz6kmvqCdZBx3Q5ZTyQQO1%2BP@mail.gmail.com> References: <AANLkTi=_mHDz3LZ1SAuCsz6kmvqCdZBx3Q5ZTyQQO1%2BP@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 21, 2010, at 9:47 AM, mdf@FreeBSD.org wrote: > I suspect this has been discussed before but I wanted to bring it up > again in light of my experience using FreeBSD as the base for a > commercial product. >=20 > Commercial life cycles can be rather long. For me, I started working > on porting Isilon's code base to FreeBSD 7.1 in May of 2009, at the > time knowing nothing about FreeBSD and extremely little about Isilon's > code base. For reference, at the time 7.1 was the most recent > RELENG_7 branch, and CURRENT had not yet been cloned into RELENG_8. > For various business reasons, at the time we did not want to track > CURRENT so settled on a local svn mirror of stable/7 to make pulling > patches easier. >=20 > Fast forward about 9 months and the merge project is complete, and > tested, and we're all happy. But FreeBSD has moved on a bit, with 8.1 > out any day now. Now fast forward another 6 months, and here we are > today, with 7.4 about to come out and EOL the stable/7 branch, and the > product based on FreeBSD stable/7 finally hitting GA. >=20 > My point in all this is that commercial software endeavors can be > multi-year efforts. But the support for stable/7 is pretty low now; I > noticed over the last year that many MFC's went to stable/8 but not > stable/7. >=20 > So the question: >=20 > Should FreeBSD support release branches for a longer time period? I > am assuming that after 7.4 comes out only security fixes will be going > into stable/7. The difficulty with supporting the release comes > partly because of KBI/ABI changes. It may be that CURRENT has changed > enough that it's just not practical to support a release that was > initially cloned 2 1/2 years ago. >=20 > For various reasons I am hoping that the next merge project we do > locally will be to CURRENT, because that makes staying in sync with > FreeBSD and returning our code to the community easiest. But making > the business case isn't quite as simple. We're still stuck on 6.x to a large degree at IronPort :(... 8.x = -- what's 8.x :/...? So yes, it would be nice to have a longer lifecycle on some = releases, but I fear that the problem is most likely scalability and = that FreeBSD needs more automated tests. It can also painful backporting = features and bugfixes to old releases, but that's a different note that = I'm sure every developer on the list is already aware of. security folks = could answer this question a lot better (cperciva, simon, et all). Thanks, -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8A01BB52-1A71-4185-9120-F36F0B6C160D>