From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 01:42:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5942E16A4CE; Mon, 12 Jan 2004 01:42:29 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18E6B43D39; Mon, 12 Jan 2004 01:42:26 -0800 (PST) (envelope-from linimon@lonesome.com) Received: from lonesome.lonesome.com (cs242719-195.austin.rr.com [24.27.19.195]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 8DF661470F; Mon, 12 Jan 2004 03:42:25 -0600 (CST) From: Mark Linimon Organization: Lonesome Dove Computing Services To: "Poul-Henning Kamp" , "Greg 'groggy' Lehey" Date: Mon, 12 Jan 2004 03:41:42 -0600 User-Agent: KMail/1.5.4 References: <33570.1073898807@critter.freebsd.dk> In-Reply-To: <33570.1073898807@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401120341.42349.linimon@lonesome.com> X-Mailman-Approved-At: Mon, 12 Jan 2004 05:18:24 -0800 cc: hackers@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 09:42:29 -0000 > I forgot to mention on rather important factor in this equation: Er, this is the *only* important factor. IMHO, it made most of the previous conversation be completely off-the-rails. > If nothing happens, vinum is going to break even more very soon. No ... if you do a commit that changes the code assumptions upon which vinum was built, vinum will break. vinum is not going to "magically" break by itself. This gets back to a problem with the FreeBSD development model: people who commit changes that break things in other parts of the system do not automatically get assigned the responsibility to fix them. Now, there's no way to impose something like that requirement on a cooperative anarchy, so I am not playing the "let's reorganize" card -- I think most of us would agree that "that dog won't hunt" as we say down around these parts. But, in the real world of software engineering, He Who Breaketh It, Must Fixeth It. Your mileage may vary. mcl