FreeBSD has serious problems with focus, longevity,
superbisquit at gmail.com
Sat Feb 18 23:58:59 UTC 2012
The individual maintainers of each architecture have the right to make
a "PRE-RELEASE" of the system at any time. Come to think of it,
anyone who can has that right- that is to make a pre-release.
On 2/18/12, Mark Linimon <linimon at lonesome.com> wrote:
> On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote:
>> 1. Incidentally, what exactly does constitute a major release?
> That point in time where we guarantee that we break a certain degree
> of backwards compatibility. (Well, that's the key component. Feature-
> additions ride on top of that.)
>> 2. Is there a reason to update the numbers so quickly?
> Yes, so that we don't have to keep supporting backwards compatibility
> for as long a period (see 1) -- it's a significant burden to maintain.
> It's necessary to do these as we rework things like network layers for
> higher performance, rework wireless to work with modern devices, and
> other high-demand items.
>> 3. Could a higher bar be set to reach a major release than simply
>> temporal objectives?
> Yes. We did that with 5.x, and blew it big-time. The goal of "rewrite
> the entire system to support SMP in a scalable, reliable fashion" was
> simply too aggressive. It led to ~5 years between major releases, and by
> that time the system had changed very dramatically (SMP, suspend/resume,
> IIRC GEOM, and too many other things to list). It was a huge jump and
> the learning curve for upgrading was way too large. We lost userbase.
> Also, keeping 5 years between major releases led to very high developer
> frustration. Why work on something when it will take 4+ years to even
> see the light of day?
> This is why we moved to the time-based releases. 18 months was seen as
> a compromise between all the various demands. Even so, we are almost
> exactly at 24 months in practice; see the graphs I updated last month as
> a result of all the recent discussion:
> My own view is that 5 years between major releases is not going to happen,
> due to how painful the 5.x experience was for all concerned. But as I'm
> not a src committer, I'm not one of the people who will be picking the
> interval for our major-branch timeline. I just try to graph it as it
> goes by.
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-hackers