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