Date: Thu, 19 Jan 2012 14:14:20 -0800 (PST) From: John Kozubik <john@kozubik.com> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <alpine.BSF.2.00.1201191402290.19710@kozubik.com> In-Reply-To: <4F172B1E.30401@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. For instance, one or more new releases has been, at least partly, justified by ZFS ... and yet it is only now with 8.3 that I'm even beginning to think of deploying. The same is true with the excellent SMP code we all now enjoy - it took until 6 to be usable. 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. > 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. > 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. That's a long time, right ? The problem is, nobody uses x.0 (maybe that's rational and maybe not, but it's a fact) so subtract 6 months there, and then if the project is even readying the next major, they're going to detach focus about 6 months prior, so subtract 6 months there ... the next thing you know I'm back where I am right now: getting *maybe* 1.5 total years of *real* lifecycle out of a major release. And since that's my major complaint, I have to disagree. And that is why I am advocating a 5 year lifespan, with at least 4 of those years being totally focused - no other "production" releases. > History tells us that 2 production branches is a goal we can achieve, > with the focus shifting more heavily towards only bug/security fixes in > the oldest branch after the new production release branch is cut. If we > combine that with the ideas that are being put forward about teams that > "own" a production branch, and a more frequent stripped-down release > process, I think this is a very workable model. Well, the top of my priority list is occupied with longer lived releases, so if we get that, and we're still maintaining two production releases, it's still a big win for me. 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. There's a reason that part of this thread got hijacked with complaints about the PR process, and that has to do with PRs getting submitted and devs deciding which production release to plug them into, etc. That's just one of many symptoms of that lack of focus.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201191402290.19710>