Mark Saad wrote: > I'll share my 2 cents here, as someone who maintains a decent sided > FreeBSD install. > > 1. FreeBSD needs to make end users more comfortable with using a > Dot-Ohh release; and at the time of the dot-ohh release > a timeline for the next point releases should be made. * > > 2. Having three supported releases is showing issues , and brings up > the point of why was 9.0 not released as 8.3 ? ** > > 3. The end users appear to want less releases, and for them to be > supported longer . > > * A rough outline would do and it should be on the main release page > http://www.freebsd.org/releases/ > > ** Yes I understand that 9.0 had tons of new features that were added > and its not exactly a point release upgrade from 8.2 , however one can > argue that if it were there would be less yelling about when version X > is going to be EOL'd and when will version Y be released. > One thought here might be to revisit the "Kernel APIs can only change on a major release" rule. It seems to me that some KPIs could be "frozen" for longer periods than others, maybe? For example: - If device driver KPIs were frozen for a longer period of time, there wouldn't be the challenge of backporting drivers for newer hardware to the older systems. vs - The VFS/VOP interface. As far as I know, there are currently 2 out of source tree file systems (OpenAFS and FUSE) and there are FreeBSD committers involved in both of these. As such, making a VFS change within a minor release cycle might not be a big problem, so long as all the file systems in the source tree are fixed and the maintainers for the above 2 file systems were aware of the change and when they needed to release a patch/rebuild their module. - Similarily, are there any out of source tree network stacks?
It seems that this rule is where the controversy of major vs minor release changes comes in? Just a thought, rick > > > -- > mark saad | nones...@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscr...@freebsd.org" _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
