From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 07:21:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AB5D1065674; Wed, 27 Feb 2008 07:21:42 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 02C0913C46E; Wed, 27 Feb 2008 07:21:41 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 27 Feb 2008 08:17:22 +0100 id 0002E00A.47C50E82.00016ADA From: Milan Obuch To: freebsd-current@freebsd.org Date: Wed, 27 Feb 2008 08:20:25 +0100 User-Agent: KMail/1.9.7 References: <47C39948.3080907@elischer.org> <47C4BB96.80804@icir.org> In-Reply-To: <47C4BB96.80804@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802270820.52816.freebsd-current@dino.sk> Cc: FreeBSD Current , Marko Zec , Marko Zec , Marko Zec , Julian Elischer , "Bruce M. Simpson" 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 07:21:42 -0000 On Wednesday 27 February 2008, Bruce M. Simpson wrote: I am not going to comment on all aspects, just some small notes... > 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. > Did you check some papers on vimage? It's purpose is virtualise network sta= ck=20 by extending jails into virtual image... From my experience it has no other= =20 impact, just enable creation of 'extended jails' with full network stack. I= =20 may be wrong on this, but this is what my reading and experience show me... > * 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. > =46rom my, not kernel developer oriented perspective, there is no change at= all,=20 just bunch of new possibilities. Naturally, there are some changes in kerne= l,=20 but as far as I can see it, they are well defined and isolated in macros, s= o=20 this mostly means almost no change, but I am not the right one to comment o= n=20 this. > [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. > This work is experimental for more than five years. I am not testing it=20 continually, but as already stated, not only by me, it is really well=20 designed framework and really well coded. I do not remember any flaw or bug= =20 in my work with it. In my eyes, it is already stable and settled enough to = be=20 introduced into main tree. > 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. > Well, I am working with FreeBSD long enough to say there are periods when e= ven=20 stable or legacy branch breaks. They are rare, to be honest, but still can = be=20 disturbing. After branching 7.0, this is the right time to introduce anythi= ng=20 new which can be considered major change, not when preparing 8.0. Regards, Milan =2D-=20 Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead.