FreeBSD has serious problems with focus, longevity, and lifecycle

John Kozubik john at kozubik.com
Tue Jan 17 18:08:35 UTC 2012


Hi Ivan,

Thanks for the insights below ... see my comments inline:

On Tue, 17 Jan 2012, Ivan Voras wrote:

>> Ability to use freebsd-update. It would be better to have more
>> frequent releases. As a prime example, ZFS became much more stable
>> about 3 months after 8.2 was released. If you were waiting for an 8.x
>> release that supported that improved version of ZFS, you are still
>> waiting.
>
> You know, that's an excellent point! And maybe an excellent idea: to
> provide occasional, time-based STABLE snapshots for freebsd-update.
>
>> You say that snapshots of STABLE are stable and effectively a running
>> release branch, so why can't more releases be made?
>
> Nobody volunteered :(


Fair enough.  Is it the case that if funds or manpower were made 
available, more releases would be workable ?  Or are there some deeper 
cultural leanings toward having fewer minor releases ?


>> Is the release process too complex for minor revisions, could that be
>> improved to make it easier to have more releases, eg by not bundling
>> ports packages?
>
> Almost certainly yes. The current release process involves src, ports
> and docs teams. Would you and other RELEASE users be happy with simple
> periodic snapshots off the STABLE branches, not much different from
> tracking STABLE? The only benefit I see would be a light-weight
> opportunity for testing which would probably end up being implemented
> by moving to date-based tags (e.g. if a critical bug is found and the
> fix MFC-ed, the "current" tag would be advanced to "$today")?


Well, as I tried to explain just previously in the thread, these need to 
be real, bona fide releases.  The notion of putting a few extra ones out 
without updating the ports tree and docs is tempting, but I think it's the 
wrong answer.  Things should be kept simple and straightforward, and all 
of the minor releases should be *real* releases.

Is three per year an insane schedule ?  Remember, I am simultaneously 
advocating that FreeBSD stop publishing two production releases 
simultaneously, which is almost oxymoronic, so presumably there are 
resources that get freed up there.


>> Can it really be that the best advice for users is to run their own
>> build infrastructure and make their own releases?
>
> Maybe. I'm trying to suggest that it looks like (I may be wrong, of
> course) that the effort required to upgrade from one RELEASE to the
> other is comparable to the effort of just having a -STABLE build
> machine somewhere and doing "make installkernel, make installworld,
> mergemaster -FU" over NFS on a 1000 machines. If you are serious about
> testing, you would need to test the RELEASEs also.


All very interesting - and honestly, things I will personally consider for 
my home filers, pfsense boxes, etc.  But no, none of my firms are going 
into the OS business - even for ourselves.


More information about the freebsd-hackers mailing list