warning of pending commit attempt.

[Bruce M. Simpson]

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