Date: Wed, 8 Feb 2012 22:33:54 -0800 (PST) From: John Kozubik <john@kozubik.com> To: freebsd-hackers@freebsd.org Subject: Moving on ... (was: Re: FreeBSD has serious problems with...) Message-ID: <alpine.BSF.2.00.1202082202530.19710@kozubik.com> In-Reply-To: <4F213CEB.4020207@herveybayaustralia.com.au> References: <20120119005658.218280@gmx.com> <alpine.BSF.2.00.1201191511470.19710@kozubik.com> <4F19188A.4090907@herveybayaustralia.com.au> <4F213CEB.4020207@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, On Thu, 26 Jan 2012, Da Rock wrote: > I normally hate to dredge up old threads, but this is like getting halfway > through a story and not finding out the ending... :) > > What is the answer? Is there a solution to this? When I wrote the original post, I was expecting at most a benign response, and at worst some real blowback ... but I was really pleasantly surprised to find that my complaints were very well received, and that a lot of folks were experiencing the same issues that I was. It appears to be a classic case of "if one customer complains, 99 others are thinking the same thing". > I have a string of questions on this: > > 1. Incidentally, what exactly does constitute a major release? I was defining major releases to be 4.x, 5.x, 6.x ... and so on. Currently 9.x is the latest major release. > 2. Is there a reason to update the numbers so quickly? I didn't think so, which was one of the main points of my post. A lot of other folks have agreed. BUT there were some counter arguments - specifically that fully new features would be delayed for a much longer time AND that there would be large architectural gulfs between major releases. For instance, we might have waited an extra 3-5 years for any ZFS support at all in a -RELEASE, and when it appeared, it would introduce a big upgrade hurdle, as it would be accompanied by major underlying changes in system architecture. But my counter to this was that a lot of these features that we did get introduced to, earlier, were in fact not really usable anyway. For instance, my firm(s) have not even considered production use of ZFS until 8.3-RELEASE. So the question remains, where do we set that dial ? If it were up to me, I think I would stake out a very loud and clear mission statement for FreeBSD that explicitly sacrifices new features for longer lifecycles and deeper investment in particular releases. I've thought seriously about the points that were made in this thread supporting faster releases, and I do appreciate what we would be giving up, but I continue to advocate for a new major release every 5 years. I don't think that's going to happen, but based on this discussion and feedback, it appears that we're going to get more frequent minor releases - possibly 3-4 per year - which makes me very happy. > 3. Could a higher bar be set to reach a major release than simply temporal > objectives? One of the differentiating factors between linux and FreeBSD is > the simple fact that linux distros tend to run so fast through the numbers- > and while just a matter of perspective, it could provide some sense of > stability to enterprise users. Weighed against, of course, the ability to > upgrade easily. I think temporal objectives are decent, provided they are long :) Long timelines give people and organizations incentive to invest time and money into a thing. I know very well of several investments in FreeBSD that my firm(s) did NOT make because we didn't think it was worth it, given that the release, and underlying arch, were going away. > 4. If in the case of the former, could some backporting to the stable and > release branches facilitate an easy upgrade to the next major release? > > 5. Could binaries be the answer to easier upgrades (customised for enterprise > users)? I think others have had better comments and insight as far as those two points are concerned. I think you would be well served to read the entire comment thread, and just ignore all of the posts that are speaking about PRs - they were off-topic almost immediately and devolved from there. A good tl;dr is from a post I made early on: <quote> You could progress 8.x along its current trajectory, possibly building 8.4 a year or so from now and then be done with it, and then that would be the last short/unfocused release. Then you postpone 10.0-RELEASE until January 2017. Instead of having a legacy branch and two production branches, you would have legacy (8) production (9) and ... nothing. Or if you need to have it out there, 10 is the development branch. Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the end of the cycle. </quote> Again, I don't think this is how it will pan out, but it was my favorite scenario. I'd be very happy and satisfied if we just got: a) more frequent (3-4) minor releases b) just one version declared as "production" at any given time[1] And I'd be pretty happy if we just got (a), which I think we will. --john [1] There were a lot of "me too" posts about more frequent minor releases, and the short lifecycle of major releases, but I was surprised that nobody else was bothered by the existence of two simultaneous "production" releases. To me it seems obviously distracting and confusing - and results in new revisions of drivers, etc., skipping the earlier "production" release. No matter where we decide to set the lifecycle dial for major releases, I really think we should rename the later one "development" ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1202082202530.19710>