Date: Thu, 19 Jan 2012 14:39:10 -0800 (PST) From: Doug Barton <dougb@FreeBSD.org> To: John Kozubik <john@kozubik.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <alpine.BSF.2.00.1201191422060.68547@172-17-198-245.tybonyfhvgr.arg> In-Reply-To: <alpine.BSF.2.00.1201191402290.19710@kozubik.com> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <alpine.BSF.2.00.1201181034580.51158@fledge.watson.org> <4F16A5B8.2080903@FreeBSD.org> <Pine.GSO.4.64.1201181147450.6287@sea.ntplx.net> <4F1707E6.4020905@FreeBSD.org> <CADWvR2ip=nADz=BLXW%2BuNkyUP4hUf88UkOhSoz%2B0AcY79Hzdag@mail.gmail.com> <alpine.BSF.2.00.1201181141270.19710@kozubik.com> <4F172B1E.30401@FreeBSD.org> <alpine.BSF.2.00.1201191402290.19710@kozubik.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Jan 2012, John Kozubik wrote: > > Hi Doug, > > On Wed, 18 Jan 2012, Doug Barton wrote: > >> On 01/18/2012 11:46, John Kozubik wrote: >>> - mark 9 as the _only_ production release >> >> While I understand your motivation, I am not sure this is a workable >> goal when combined with the goal that others have expressed of longer >> timelines for the support of a given branch. Speaking from personal >> experience, once a service is released on a given platform the costs of >> migration can be significant. And if what I have is working well and >> only needs the occasional bug/security fix my motivations for migration >> are near zero. So the tradeoffs then become more frequent major releases >> to get new features, vs. longer support for a given release branch. > > > Agreed. What I am saying is that that "dial" is currently set incorrectly. > I think we should sacrifice new features for longer lived releases. There are at least 2 problems with that. First, often the new features are either really useful, or actually necessary. Second, "getting new features into a production release" is one of the motivating factors for FreeBSD developers. Yes, I agree with others in this thread that the pendulum has swung too far in allowing people free reign with little/no responsibility for followup. But we still have to acknowledge that reality. > My own experience has been that all of the new features I have benefited from > did not start being useful until several releases past their introduction. I both understand this, and have experienced it myself. The answer to that is to raise the bar higher for what goes into HEAD, such that more developers (and especially users) can be using it on a more frequent basis. In that way fewer bugs exist in the first place, and the ones that exist (because of hardware differences, etc.) are found and fixed prior to the .0 release. > That would suggest that the end users don't really lose on features by > delaying the new releases, since those features typically aren't ready > anyway. I think "typically" is stretching it a bit here. As humans we tend to focus our attention on the things that cause us problems, rather than acknowledging (or even being aware of) the things that are working well in the background. >> Let's take 5 years as a reasonable time period for supporting a branch. >> Waiting that long between major releases would significantly stifle the >> ability to add new features that require breaks to the [AK][BP]I. It >> would also inhibit our ability to do revolutionary architectural changes >> such as moving to clang as the primary supported compiler. > > > I agree. Those are costs I am willing to pay, and I think the response to > this thread shows that a lot of other folks would prefer that cost/benefit > setting to the current one. Personally, that message has been clearly understood. So the challenge at this point is to come up with a plan that can accomplish as much as possible of what the users need while still being sufficiently attractive to our volunteer developers to actually get things done. >> What I've proposed instead is a new major release every 2 1/2 years, >> where the new release coincides with the EOL of the oldest production >> release. That way we have a 5-year cycle of support for each major >> branch, and no more than 2 production branches extant at one time. > > > I think that at first glance, 2.5 or 3 years sounds completely reasonable. You're not following the math. :) I'm proposing a 5 year support cycle for each production branch. > But in the bigger picture I think having two production releases > simultaneously, while possible, is a bad idea. You have to optimize for > something, and in practice I think both lose out. This isn't a FreeBSD > issue, it's a classical resources issue. I freely concede that 2 production releases is stretching us to the limit of our abilities. I think that this will be improved by the idea of having teams of developers who are responsible for shepherding each production branch. But now speaking as a consumer of FreeBSD, 2 production branches is something that *I* definitely want. If for no other reason than because it gives me options in case the newest one doesn't work out for me for some reason. It also helps with the ".0 problem" that you're concerned about, although I am still hopeful that we can fix that problem by actually fixing that problem. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201191422060.68547>