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.
_______________________________________________
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"

Reply via email to