Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Jan 2012 10:08:28 -0800 (PST)
From:      John Kozubik <john@kozubik.com>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        Tom Evans <tevans.uk@googlemail.com>, freebsd-hackers@freebsd.org
Subject:   Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Message-ID:  <alpine.BSF.2.00.1201170958110.19710@kozubik.com>
In-Reply-To: <CAF-QHFV8oj=ipwcsVo3e3P3kgGBPr%2Bz1gRzn3D3PT%2Bc0pHJtcQ@mail.gmail.com>
References:  <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <jf3mps$is3$1@dough.gmane.org> <CAFHbX1%2Bi3JwCCBmqtOsW6m74VpDBSAmBOt7CPcCGAPCO2DBDkA@mail.gmail.com> <CAF-QHFV8oj=ipwcsVo3e3P3kgGBPr%2Bz1gRzn3D3PT%2Bc0pHJtcQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1201170958110.19710>