[Libguestfs] 1.39 proposal: Let's split up the libguestfs git repo and tarballs

[Richard W.M. Jones]

My contention is that the libguestfs git repository is too large and
unwieldy.  There are too many separate, unrelated projects and as a
result of that the source has too many dependencies and takes too long
to build and test.

The project divides (sort of) naturally into layers -- the library,
the bindings, the various virt tools -- and could be split along those
lines into separate projects which can then be released and evolve at
their own pace.

My suggested split would be something like this:

* libguestfs: The library, daemon and appliance.  That would include
  the following directories in a single project:
       appliance
       bash
       contrib
       daemon
       docs
       examples
       gnulib
       lib
       logo
       test-tool
       tmp
       utils
       website

* 1 project for each language binding:
       csharp
       erlang
       gobject
       golang
       haskell
       java
       lua
       ocaml
       php
       perl
       python
       ruby

* virt-customize and related tools, we'd probably call this subproject
  "virt-builder".  It would include virt-builder, virt-customize and
  virt-sysprep, since they share a lot of common code.

* 1 project for each of the following items:

       small tools written in C
          (virt-cat, virt-filesystems, virt-log, virt-ls, virt-tail,
	   virt-diff, virt-edit, virt-format, guestmount, virt-inspector,
	   virt-make-fs, virt-rescue)

       guestfish

       virt-alignment-scan and virt-df

       virt-dib	   

       virt-get-kernel

       virt-resize

       virt-sparsify

       virt-v2v and virt-p2v

       virt-win-reg

* I'd be inclined to drop the legacy Perl tools virt-tar,
  virt-list-filesystems, virt-list-partitions unless someone
  especially wished to step forward to maintain them.

* common code and generator: Off to the side we'd somehow need to
  package up the common code and the generator for use by all of the
  above projects.  It wouldn't be a separate project for downstream
  packagers, but instead the code would be included (ie. duplicated)
  in tarballs and upstream available as a side git repo that you'd
  need to include when building (git submodule?).  This is somewhat
  unspecified.

M4, PO, and tests would be split between the projects as appropriate.

My proposal would be to do this incrementally, rather than all at
once, moving the easier things out first.

Thoughts?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org