[Spice-devel] repository reorg

[Alon Levy]

On Wed, Jun 22, 2011 at 08:14:57PM +0300, Uri Lublin wrote:
> On 06/22/2011 06:00 PM, Alon Levy wrote:
> >Hi All,
> >
> >  We currently have the following repositories:
> >   spice-protocol
> >   spice
> >   spice-gtk
> 
> also
>      spice-vdagent (for both Windows and Linux)
>      spice-xpi/active-x (as mentioned below)
> 
> >
> >  spice-protocol contains the following parts:
> >   qxl_dev.h - required by qemu and drivers
> >   controller.h - required by spice client and xpi/active-x
> >   the rest - protocol definitions for server and client
> >
> >  spice is composed of
> >   codegen - generation of marshallers, demarshallers, and defines that go into spice-protocol.
> >   server - server implementation
> >   client - old client implementation
> >   common - shared by server and client, further subdivided to:
> >    glz/lz/quic encoders and decoders
> >    cache implementation
> >    canvas rendering implementation
> >    used by the server, old client and new client.
> >
> >  Inefficiencies with the current repositories:
> >   1. updates to the protocol need to go to spice/spice.proto, run the codegen,
> >     and put the results to spice-protocol
> >   2. common exists in both spice and spice-gtk. since it hasn't been touched in
> >     a while it isn't a real problem, but still the code duplication is bad and
> >     in the future (3d canvas) it will be modified.
> >
> >  Suggested changes:
> >   spice - merge spice-protocol into it
> >   spice-protocol - kill it
> 
> What will you do with other components that require spice-protocol,
> such as spice-vdagent.
> 

we will still package spice-protocol as an rpm, and if you want to build from git
you would just make install the server instead of the spice-protocol.

> >   common - extract to a separate library, it's own configure, pkg-config, name it spice-render,
> >    and have spice-gtk and spice (server and old client) rely on it.
> >   spice-gtk - keep it as is. easier to develop with a separate configure since it doesn't contain
> >   all the requirement checks for the server.
> 
> Many times changes in "common/" files come with changes in "server/"
> or "client/" files (for example, adding a parameter to an existing
> function, or adding a new function). So we're back to committing
> into two repositories (plus synchronizing their versions).
> 
> Maybe using git magic is a better solution (?).
> Specifically I'm thinking of "git submodule", but there may be a better way.
> 

I don't know what is better :( I'm ok with having a git submodule for common.

> Uri.
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel