Hi John, > -----Original Message----- > From: John Kozubik [mailto:j...@kozubik.com] > Sent: Tuesday, January 17, 2012 3:52 PM > To: Devin Teske > Cc: 'Garrett Cooper'; wbent...@futurecis.com; freebsd-hackers@freebsd.org > Subject: RE: FreeBSD has serious problems with focus, longevity, and lifecycle > > > 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 too am not sure. The latter (pick a "chosen" release) option seems a good route, but like you say, maybe a re-envisioning of the release procedure is what's needed for long-term. > 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. > I often have to deal with "FUD" at work, especially when the developers learn that FreeBSD has, for example, released FreeBSD 9.0 somewhat indicating that "oh, no -- we're obsolete?!" In which I've always had to then explain how "FreeBSD has three versions running simultaneously at all times -- a legacy release, a stable release, and a future release," and they are happy with such an explanation. I usually then go on to explain "back in the day it was 4/5/6, and now it's 8/9/10". Naturally, this is an over-simplified view of the situation, but it sure would be a nice view if it were absolutely true. There ought to be a charter that explicitly defines the types of things you can expect from each release (regardless of which release): For example, the "legacy" release (which might as well be 8.x now) should: a. Receive all security patches until deprecated b. Receive critical bug fixes until deprecated c. Benefit from trivial hardware device additions (e.g., developer adds "0x10de" device identifier to if_bgereg.h to add new hardware support to bge(4)) Meanwhile, the "stable" release (which might as well be 9.x now) should: a. Receive all security patches b. Receive critical bug fixes c. Benefit from ALL hardware device changes except experimental ones and those that completely redesign the driver Last, the "current" release (which might as well be 10.x now) should: a. Be the landing zone for all new code, experimental or otherwise. Finally, the charter ought to also define when a "current" can become "stable" ... not define some arbitrary timeline which results in situations like that which was previously mentioned in this thread (9.0 shipped as stable release with completely broken gmultipath). > 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. > +1 > Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the > end of the cycle. > Ought we to have one timeline for stable (aka production) and a different timeline for legacy? Say, cut a new release in legacy 1-2 times a year and cut a new release in production 2-3 times a year? Just an idea. > 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 ? Our firm has chipped in (significantly) in the past, and I'm starting to think it's 'bout time we do it again. But if we're going to do so, we would want written statements as to what we're paying for. I think it's worth opening the discussion to all potential investors to see: if money were thrown at the problem, what could be achieved? what would the charter look like? is there even enough like-minded investors that a consensus could be reached for a common goal? -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
