FreeBSD has serious problems with focus, longevity,
and lifecycle
Mark Felder
feld at feld.me
Wed Jan 18 20:21:05 UTC 2012
On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik <john at kozubik.com> wrote:
>
> And as long as we're repeating ... :)
>
> Since 9.0 is already out of the bag, I think a decent approach would be
> to fizzle out 8.x on the current timeline/trajectory (maybe 8.4 in 6-8
> months, and maybe 8.5 in a year or so), then:
>
> - EOL 7
> - mark 8 as legacy
> - mark 9 as the _only_ production release
> - release 10.0 in January 2017
>
> And in the meantime, begin the every 4-6 month minor releases that we
> all agree can occur with 9. By Jan 2017, you get to 9.12 or 9.14 or so.
>
> This is nice because no upheaval needs to happen with 7 and 8, and
> interested developers do not get kneecapped vis a vis 9 - they can just
> keep going where they were going with it, and the only real change is
> that 10 is pushed out a long ways, and people[1] get to really sink
> their teeth into 9.
>
What are the policies for changes though? Are we stuck with 9.0's feature
set for 5 years? Will we have to wait 5 years to get a stable release of
FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's
also a huge changeset. How will things like this be dealt with? Five years
is a long time for the next stable release if we have a policy to not
import major changes from -CURRENT. It would be devastating to so many
users.
More information about the freebsd-hackers
mailing list