Ivan Voras | 17 Jan 12:41 2012
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

(answering out of order)

On 16/01/2012 23:28, John Kozubik 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.

You could say the question is: why is it so, but I think you know the 
answer to that: small project, not enough manpower and volunteer-hours. 
However, the situation is actually quite good because the developers are 
usually very responsive to MFC requests...

> 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).

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.

> 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.

> A few years ago we were dying for new em(4) and twa(4) drivers in
> FreeBSD 6, but they were applied only to 7 and beyond, since that was
> the "new production" release (as opposed to the "old production"
> release). It's the same bad choice again: make major investments in
> testing and people and processes every two years, or just limp along
> with old, buggy drivers and no support.

Have you tried contacting the developers of those drivers? The most 
likely causes the drivers weren't MFC-ed are either that they were 
experimental enough that it was feared for their stability or that they 
didn't think anyone needs drivers MFC-ed.

The situation you describe is certainly not FreeBSD-specific: Debian is 
notoriously slow in adopting new features, but so is Red Hat Enterprise 
Linux, which had the ancient (2006 vintage) 2.6.18 kernel throughout its 
5.x cycle (still active in 2011) - though updated with new drivers. 
Compared to these, FreeBSD is in many ways a pleasure to work with.

Seriously, just think of -STABLE as a "rolling release", just like the 
ports tree.

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"


Gmane