Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Blue Swirl]

On 1/6/09, Frank Mehnert <address@hidden> wrote:
> Hi,
>
>
>  On Tuesday 06 January 2009, Anthony Liguori wrote:
>  > Frank Mehnert wrote:
>  > > On Wednesday 24 December 2008, Anthony Liguori wrote:
>  > >> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
>  > >> bunch of QEMU code and AFAIK has not shared any of their changes back
>  > >> with the QEMU community.  They are completely entitled to do this of
>  > >> course based on the licensing of QEMU.
>  > >
>  > > Sorry, that is not true.
>  >
>  > As I said, sharing implies a two-way exchange.  The VirtualBox
>  > development was not done publicly and to the best of my knowledge, no
>  > attempt has been made by the VirtualBox developers to push any of their
>  > changes back into QEMU.  All other virtualization projects (Xen and it's
>  > variants, KVM, etc.) have made an attempt to push changes back to QEMU.
>  >
>  > Yes, you have a public SVN that appeared long after your development
>  > started.  Are we supposed to troll through it looking for changes that
>
>
> Our subversion repository is public since January 2007, so for more than
>  two years. It is true that we did internal releases before we started to
>  go public but I don't understand why do you complain. Note that we were
>  customer-driven from the beginning, unlike, for instance, Xen, which
>  was a community project when it started.
>
>
>  > may or may not be applicable to upstream?  It's extraordinarily
>  > difficult because you've made a huge number of changes to your QEMU fork
>  > that have nothing to do with bug fixes.
>
>
> Believe me, it is difficult for us too, to follow the changes in Qemu.
>  And we use only a part of the Qemu code. As you mentioned in an earlier
>  post, VirtualBox and Qemu are quite different. We execute many code
>  inside the guest context (for performance reasons) while Qemu recompiles
>  the guest code in the context of the host. We depend on the Qemu code for
>  more rare cases where other mechanisms don't work (e.g. real mode). So
>  the most changes we did were adaptions to our environment.
>
>
>  > This is not how Open Source development works.  You don't make a bunch
>  > of changes private, put out a repo after the fact, and make no attempt
>  > to work with any of the projects you took the majority of your code
>  > from.  You can call it open all you want but it simply isn't.  We won't
>  > even get into the whole contributor agreement non-sense.
>  >
>  > >> Some of their most interesting changes (like SATA emulation, rewritten
>  > >> USB emulation) remain available only in their closed source version.  I
>  > >> find that extremely unfortunate because that would be some of the
>  > >> easiest and most useful code to try to merge from their project.
>  > >
>  > > Some of these parts might be available under GPL in the future.
>  >
>  > That would be nice but I'm not going to hold my breathe.
>
>
> Do you really know our public SVN? The majority of the code was written
>  from scratch and the most interesting parts are available for public
>  re-use.

I tried to merge some slirp bits once:
http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00470.html

Of course it would be much easier for all of us if someone submitted
the changes one at a time, each change described properly and patches
generated against current Qemu SVN.