From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 17 18:08:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D60106564A; Tue, 17 Jan 2012 18:08:35 +0000 (UTC) (envelope-from john@kozubik.com) Received: from kozubik.com (kozubik.com [216.218.240.130]) by mx1.freebsd.org (Postfix) with ESMTP id E036C8FC14; Tue, 17 Jan 2012 18:08:34 +0000 (UTC) Received: from kozubik.com (localhost [127.0.0.1]) by kozubik.com (8.14.3/8.14.3) with ESMTP id q0HI8X6m045632; Tue, 17 Jan 2012 10:08:33 -0800 (PST) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.14.3/8.14.3/Submit) with ESMTP id q0HI8SCr045629; Tue, 17 Jan 2012 10:08:28 -0800 (PST) (envelope-from john@kozubik.com) Date: Tue, 17 Jan 2012 10:08:28 -0800 (PST) From: John Kozubik To: Ivan Voras In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Tom Evans , freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:08:35 -0000 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.