From owner-freebsd-stable@FreeBSD.ORG Thu Dec 22 22:06:23 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 018BD16A41F; Thu, 22 Dec 2005 22:06:23 +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 3319F43D4C; Thu, 22 Dec 2005 22:06:22 +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 jBMM6HQN083673; Thu, 22 Dec 2005 14:06:18 -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 jBMM5W55059648; Thu, 22 Dec 2005 14:05:32 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBMM5Wk9059647; Thu, 22 Dec 2005 14:05:32 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 14:05:32 -0800 From: Jo Rhett To: Brooks Davis Message-ID: <20051222220532.GL39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <20051222211019.GI39174@svcolo.com> <20051222213041.GA5746@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051222213041.GA5746@odin.ac.hmc.edu> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: Wilko Bulte , stable@freebsd.org, current Subject: Re: HEADS UP: 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:06:23 -0000 On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote: > This statement makes no sense. The core team wouldn't have much to > do with this other than possibly being involved in making any service > official. Also, approval is never given to include a non-existent > feature. Easy, binary updates sound like a great idea, but without > seeing actual code thats all anyone can say other than offering advice. > If volunteering is conditional on acceptance of the work, that's a > chicken-egg problem and is not resolvable. We simply can't maintain > quality if we accept non-existent code just because the idea sounds > good. What are you talking about? These issues have been repeatedly brought up in the mailing lists, and what it would require to make it possible to handle appropriately (namely, core os packages or a similar versioning mechanism) and the arguements have often been given. And many people _ARE_ already trying to handle binary updates without core OS support. We are all struggling with the same limitations. Talk to the security officer about this if you don't believe me. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation