Hi On Thu, Jun 23, 2011 at 1:10 PM, Alon Levy <al...@redhat.com> wrote: > On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote: >> On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote: >> > Hi All, >> > > Ok, so take three: > > (1) spice-protocol - remains unchanged. specifically, despite the name, will > not contain the .proto nor the python codegen bits nor the generated files.
I fail to see why that couldn't be part of a spice-common/protocol subdirectory, and shipped as a seperate devel package by distributions. But I didn't read all the conversation. Can you briefly give the rationale of the changes in your upcoming propositions? > (2) spice-common (repository spice/common) - new repository, contains: > spice*.proto > spice_codegen.py and friends (python_modules subdir) > produces a proper shared library, used by spice-server, spice-client, > spice-gtk, named > libspice-common.so.0, containing marshalling and rendering code (including > any decoder/encoder) > plus anything else currently in common (like ssl-verify). That's an ideal goal, but to avoid having to deal with creating a proper library (with stability garantee etc..), I would start with a submodule that will slowly move to various clean lib*. > (3) spice-client - breakoff client subdir from current spice (maybe > rename+remove-the-rest to keep history) Agree with the fact that it should be split off. But since it's not going to be the officialy maintained spice-client, I would suggest the name "spicec" instead. > (4) spice-server - rename current spice repo (just to keep history) > (5) spice-gtk - remains, just move it to freedesktop now that we want to > keep it. ack > (6) spice-all - convenience repository that has the rest as submodules and > has a helpful makefile to build them all. Well, why not just use jhbuild? it does the job fine.. -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
