17 Jan 2012 12:41
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Ivan Voras <ivoras <at> freebsd.org>
2012-01-17 11:41:48 GMT
2012-01-17 11:41:48 GMT
(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"