Date: Tue, 21 Dec 2010 15:00:15 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: mdf@freebsd.org Subject: Re: Schedule for releases Message-ID: <201012211500.16131.jhb@freebsd.org> 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 Tuesday, December 21, 2010 12:47:08 pm 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. > > 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. > > 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. > > 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. > > So the question: > > 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. That has been my concern from the beginning with the aggressive release schedule we adopted several years ago. None of the companies I have worked at were in a position to track FreeBSD release branches as often as they are created. The counter-argument that I have always heard is that vendors who use FreeBSD in this manner are free to skip branches, say, from 7 to 9. I'm a bit on the fence on this one. On the plus side, the the merges necessary to go from 6 to 7 or 7 to 8 were far easier than going from 4 to 5 (or 4 to 6). I think even 6 to 8 would likely be fairly manageable. OTOH, I know that as a developer it's a good bit of extra work to merge changes back to 2 stable branches (7 and 8) rather than just one. I do think that the current schedule was in large part a reaction to how long 5.0 took, but I also think that 5.0 was an aberration, and not necessarily the common case that all of our release planning should be based on. Had we not yet released 8.x I think 7.x would still have a good bit of life left in it. It is possible to merge at least some large changes to a stable branch (e.g. superpages to 7). I expect to start working on merging the vm_page locking changes to 8 in the near future for example. I think the current pace of releases probably works well for users (or at least the current pace of features). If we were to aggressively merge a lot of the changes in 9 to 8 for 8.3 then I could see putting off 9.0 for a while and giving 8.x a longer lifespan perhaps, but that it is too late to do that for 7, and I'm not sure if other developers would be up for that or not. I'm not entirely sure what the right answer is, but this is something that has worried me for a while. > 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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012211500.16131.jhb>