From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 01:41:23 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D831106566C; Wed, 27 Feb 2008 01:41:23 +0000 (UTC) (envelope-from bms@icir.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3A99113C478; Wed, 27 Feb 2008 01:41:23 +0000 (UTC) (envelope-from bms@icir.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 421A7A1CE6; Tue, 26 Feb 2008 20:23:37 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 26 Feb 2008 20:23:37 -0500 X-Sasl-enc: q2fqJ46SXrBocLgAt+bdGafQdc0yfgdf3S39zjFjbhBV 1204075416 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id BC9A023455; Tue, 26 Feb 2008 20:23:35 -0500 (EST) Message-ID: <47C4BB96.80804@icir.org> Date: Wed, 27 Feb 2008 01:23:34 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Julian Elischer References: <47C39948.3080907@elischer.org> In-Reply-To: <47C39948.3080907@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Feb 2008 02:15:50 +0000 Cc: Marko Zec , Marko Zec , Marko Zec , FreeBSD Current Subject: Re: warning of pending commit attempt. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 01:41:23 -0000 Julian Elischer wrote: > > what do we gain? > Jail on steroids > A framework that can be extended to other virtualisation avenues. > The ability to have full virtual machines on almost any layout > of physical hardware. I'm confused by the above statements. Also somewhat bemused by them, given that our track record for regression testing and documentation ain't always that great either -- and when bold new ideas are proposed, due diligence often saves the day. * Do you mean to say that IMUNES/vimage has expanded beyond merely wrapping the network stack and virtualizing that? If this is the case (it introduces some new virtualization technique on par with the functionality of e.g. Xen) then I outright DISAGREE with its introduction into the source tree on the grounds that it's too experimental. * Also, do the changes which you intend to introduce, allow for code which is currently under development, and which is not aware of vimage/IMUNES in any way, to continue to compile and be usable without additional developer time? I am continually sidetracked from FreeBSD infrastructural work because it just doesn't pay the bills. As a result I have to defer work for up to a year at a time. If there were community funding available this would help, but as it is, I have to keep the plates spinning somehow. I usually try to keep my p4 development branches merged and in sync at a minimum, so I can always diff against HEAD. [Julian, you're not about to give people a real headache with this, are you?] * If the objective of the exercise is to expose people to vimage, would it not be wiser to implement vimage as a fork in a more accessible repository format than Perforce? e.g. Mercurial or Git? I am opposed to trial-by-fire. I am just as frustrated with the lack of progress which is visible to people on the outside of the development cabal as anybody else (just try to get people to test code in Perforce when they aren't committers, and you'll see EXACTLY what I mean), but I really don't like the idea of experimental work going into CVS. Whilst CVS is a proven tool, its use in the project, to my mind, seems more geared to delivering production code and tracking changes in production branches, rather than managing fast-moving new development. * Does the vimage code have a full set of regression tests which prove that its introduction does not cause the system to behave in an unexpected way? These are very real concerns and they do need to be addressed, otherwise I speculate this is going to be messy, and I don't want to see a repeat of FreeBSD 5.x. Don't get me wrong, there is excellent reasoning and art behind the work in vimage, but the very real economic difficulties involved in its integration just cannot be ignored as they affect everyone involved with the project. best regards, BMS