From owner-freebsd-stable@FreeBSD.ORG Thu Dec 22 22:12:38 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03E3216A41F; Thu, 22 Dec 2005 22:12:38 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FE4B43D60; Thu, 22 Dec 2005 22:12:34 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBMMCRQP083877; Thu, 22 Dec 2005 14:12:28 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBMMC3Gx061148; Thu, 22 Dec 2005 14:12:03 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBMMC2pI061139; Thu, 22 Dec 2005 14:12:02 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 14:12:02 -0800 From: Jo Rhett To: Chuck Swiger Message-ID: <20051222221202.GM39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <20051222205725.GD39174@svcolo.com> <43AB1E65.2030501@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43AB1E65.2030501@mac.com> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2005 22:12:38 -0000 On Thu, Dec 22, 2005 at 04:45:09PM -0500, Chuck Swiger wrote: > FreeBSD releases new .ISO images several times a year, but you've got the > tools to make .ISO images of patch releases yourself, if you want to. I > don't think that the FreeBSD project can shorten the release cycle below a > month or so, which means that patch releases are always going to be on the > (b)leading edge... I'm not sure you're paying attention to what I'm saying. This was your reply to my message about systems without CDs, with only flash drives, etc. ISOs won't help. > >And taking systems offline for a .1 > >update gets annoying fast. Dealing with all the file comparisons which are > >exactly the same except for the CVS tag takes hours for no good reason. > >Multiple many hours by hundreds of systems, and you could easily have a > >full time person just doing FreeBSD upgrades. > > Using a build server as a testbed and to generate new packages or even a > new kernel + world will reduce the amount of work required, but FreeBSD > does require some level of administration and maintenance. We already have that. But again, I'm not sure what you are trying to say here. The centralized server makes patching and port upgrades easier. It does _NOTHING_ for core OS upgrades because there is no supported mechanism for doing binary upgrades except from the ISO. Thus, we are finally back on topic. > >I don't care about ports, just the base OS. Ports we've built the > > I've got firewalls with a single-digit number of ports installed, but > anything else seems to acquire 100-200 or so. Again, I don't care about ports. The largest number of ports installed on any production system we have is 18. And having a centralized server where we can build and export the packages works just fine. The portaudit tools are very useful in this regard, when pointed at internal servers. There is no similar mechanism for OS upgrades, which is what we're talking about here. Ports is not a problem. > I'm with you on this, but suggesting solutions is more useful than just > noting the existence of problems. I have made suggestions. Everyone has made suggestions. Most of us have produced code to work around the problem, but the core OS team has always refused to support or acknowledge these efforts. For binary upgrades without booting from CD-ROM to be possible, we need versioning of some sort at the OS level. Core OS packages are the most popular suggestion, but not the only path. Every year this topic comes up and gets struck down again. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation