Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Jan 2012 09:52:27 -0800 (PST)
From:      John Kozubik <john@kozubik.com>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Message-ID:  <alpine.BSF.2.00.1201170923530.19710@kozubik.com>
In-Reply-To: <jf3mps$is3$1@dough.gmane.org>
References:  <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <jf3mps$is3$1@dough.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Ivan,

On Tue, 17 Jan 2012, Ivan Voras wrote:

>> 2) Having two simultaneous production releases draws focus away from
>> both of them, and keeps any release from ever truly maturing.
>
> This isn't how things work. The -CURRENT always has (and probably always had 
> and always will have) the focus of developers. The "releases" are for many 
> people simply a periodical annoyance due to freezes. In no way will reducing 
> the number of "production releases" change this. As a volunteer effort, 
> backports to stable branches only happen when 1) it's in the interest of the 
> developer, e.g. "I've found a bug on my systems, want to get it fixed in 
> -STABLE" and 2) when the developer is budged by outside forces (users 
> complaining, other developers requesting it) and 3) they think it's worth 
> doing and have time to do it spontaneously. These are in order of likelihood 
> to happen.


I could not have illustrated my point better, RE: FreeBSD becoming an OS 
by, and for, FreeBSD developers.

I wish I could find the quote - it was from one of the FreeBSD core team 
many years ago, and it was something along the lines of "we are holding 
a piece in one of the highest stakes games in the modern world".  Now 
juxtapose that with "The "releases" are for many people simply a 
periodical annoyance".


>> going to
>> run RELEASE software ONLY
>
>> 4) New code and fixes that people NEED TODAY just sits on the shelf for
>> 8 or 10 or (nowadays) 13 months while end users wait for new minor
>> releases.
>
> ... except if you expect regular releases :)
>
> I've concluded very early that because of what I've said above, the only way 
> to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff 
> usually try hard not to break things so -STABLE has become a sort of "running 
> RELEASE" branch. Since -STABLE is so ... stable ..., there is less and less 
> incentive to make proper releases (though I think nobody would mind it 
> happening).


Impossible.  I'm not a FreeBSD guy, I'm a business owner.  Like most 
businesses, we are running official, delivered, release software only. 
Controller firmware ?  Release only.  Motherboard BIOS ?  Release only. 
Drivers ?  Release only.  Just because I *happen* to also have some 
techincal expertise with FreeBSD, and some geeky tendencies does not mean 
we're making any exceptions.


> The next question is: what do releases from a -STABLE branch bring in that 
> simply tracking the original -STABLE tree doesn't? Lately, not very much. 
> Since there is a huge number of users and developers tracking -STABLE, the 
> testing done specifically for a X.Y, Y>0 RELEASE is not very extensive, so 
> you just as well could have tracked -STABLE.
>
> I'm sure you know how easy it is to upgrade a STABLE-running system, and 
> there are simple ways in which that can be made to scale to thousands of 
> machines. Breakage is of course a risk, but not significantly greater than 
> for any other upgrading.


If we lose an rsync.net storage array, we'll get sued in 50 countries. 
My family and I will be *fucked*, not to mention the thousands and 
thousands of people, possibly ruined, around the globe.

Now let's explain to one of those folks (or a judge and jury) (or my wife 
and kids) how the STABLE track works.  Presumably they will refer us 
directly to the FreeBSD projects home page, where they had found:

"This is still a development branch, however, and this means that at any 
given time, the sources for FreeBSD-STABLE may or may not be suitable for 
any particular purpose. It is simply another engineering development 
track, NOT A RESOURCE FOR END-USERS."


>> of 2012, we should be on 6.12 (or so) and just breaking ground on 7.0.
>> Instead, each release gets perhaps two years of focused development
>> before every new fix is applied only to the upcoming release, and any
>> kind of support or enthusiasm from the community just disappears.
>
> If you're saying that -STABLE branches don't get fixes fast enough, I'd 
> disagree.


I'm not saying that.  I'm not a FreeBSD developer and I have little use 
for either CURRENT or STABLE.  I'm saying that I need a major release to 
have an *effective* lifetime longer than two years.

Nobody runs the x.0, and these days the next major release comes in 
concurrent with x.2 ... so that's x.1 and x.2 you get to use in a real 
world, enterprise setting, before you have to either:

a) scrap that investment and start a new round of investment in the new 
release (not trivial for a global firm)

b) begin limping along as a second class citizen, watching everything - 
not just new features, but necessary bug fixes, go into the next major.


--john



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201170923530.19710>