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