Date: Tue, 17 Jan 2012 15:52:22 -0800 (PST) From: John Kozubik <john@kozubik.com> To: Devin Teske <devin.teske@fisglobal.com> Cc: 'Garrett Cooper' <yanegomi@gmail.com>, freebsd-hackers@freebsd.org, WBentley@futurecis.com Subject: RE: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <alpine.BSF.2.00.1201171525240.19710@kozubik.com> In-Reply-To: <03a901ccd56d$09eb2a20$1dc17e60$@fisglobal.com> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <CAGH67wS3mvPCBKG36iQ8qtA89GGk1r3KEp4QHj6nt8y9nB8uEA@mail.gmail.com> <03a901ccd56d$09eb2a20$1dc17e60$@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Devin, On Tue, 17 Jan 2012, Devin Teske wrote: > I brought this up in last weekend's BAFUG meeting... > > We're _very_ interested in replicating the long-lifecycle of the 4-series with a > newer series. But which one? > > Right now, we're jumping to the 8-series, but after seeing that one of the major > focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j > enable), I'm ready to say that the 9-series should instead be the "chosen > outlier" when it comes to picking one single release to have an ultra-wide > lifecycle. > > The 9-series represents the first release to integrate a journaled filesystem > by-default into the system (aka boot) filesystem(s). We were pleasantly > surprised to see that the default installer enabled SU+J by-default when > choosing "guided" and "auto" for disk partitioning. There's two parallel suggestions being put forth here, both of which are interesting: - Allow a related party to adopt a release (as I understand it) and provide a sub-community taht donates resources to tending and updating that release. - Picking a "chosen" release to really dive into, officially, and polish and extend it, like 4. If I had to pick, I'd say the second one, but I'm not sure either one is the right direction. I think a more sustainable, balanced approach that can be extended for every release into the future would be best. I don't really want to see some semi-official "fork", or "extended release" - it would duplicate a lot of existing effort as well as raise questions about how "official" it was. Would vmware support it as a real release ? Large organizations might disqualify it the same way they would STABLE. As for picking 8 or 9 to be the "chosen" exception - that would help me a lot in the short term, but if things are being done wrong, they should be fixed in the long run. I think the real choice that has to be made is "when will we halt proclaiming two simultaneous releases as production ?" and since 9 is already here, it can't be 8/9, it has to be 9/10. 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. On Tue, 17 Jan 2012, Adrian Chadd wrote: > OP - if you'd like to see FreeBSD's stable release schedule pushed > forward a bit quicker then please, step up and offer to assist. No-one > is going to say no. Everyone will appreciate the extra help. I don't really know how much upheaval is implied in pushing 10.0 to 2017, developing only one "production" release, and running 9.x up to 9.15 (or whatever) but I can contribute USD $10k per year that this course was followed, or $50k over five years. We can contribute some hardware, hosting and bandwidth as well. Are there any others here who can chip in, or whose firms can ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201171525240.19710>