warning of pending commit attempt.
Bruce M. Simpson
bms at icir.org
Wed Feb 27 01:41:23 UTC 2008
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
* 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
* 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
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
More information about the freebsd-current