Re: warning of pending commit attempt.

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 stack 
by extending jails into virtual image... From my experience it has no other 
impact, just enable creation of 'extended jails' with full network stack. I 
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.
>

From my, not kernel developer oriented perspective, there is no change at all, 
just bunch of new possibilities. Naturally, there are some changes in kernel, 
but as far as I can see it, they are well defined and isolated in macros, so 
this mostly means almost no change, but I am not the right one to comment on 
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 
continually, but as already stated, not only by me, it is really well 
designed framework and really well coded. I do not remember any flaw or bug 
in my work with it. In my eyes, it is already stable and settled enough to be 
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 even 
stable or legacy branch breaks. They are rare, to be honest, but still can be 
disturbing. After branching 7.0, this is the right time to introduce anything 
new which can be considered major change, not when preparing 8.0.

Regards,
Milan

-- 
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.