On Tue, Sep 15, 2009 at 11:38:19AM +0100, Daniel P. Berrange wrote:
> With the 0.7.1 relesae out of the way I'd like to suggest that we take 
> this time to move around some files in GIT to correct some long standing
> wierd/bad naming decisions :-)
> 
> 
> The qemud/ directory is better named 'daemon', and some of the things
> in there should really have been in the src/ directory. So...
> 
>  * qemud/ -> daemon/
>  * qemud/qemud.{h,c} daemon/main.{h,c}
>  * qemud/default-network.xml ->  src/network/default.xml
>  * qemud/libvirtd_qemu.aug src/qemu/qemu.aug
>  * qemud/test_libvirtd_qemu.aug src/qemu/test_qemu.aug
>  * qemud/remote_protocol.x -> src/remote/remote_protocol.x

  ACK, though daemon/main.{h,c} could be libvirtd.{h,c}, not a big deal
  though


> In the src/ directory we should move the rest of the drivers into their
> own sub-directories. Basically want one sub directory for each of the
> 'mod_LTLIBRARIES' declared in the src/Makefile.am. This will ensure we

  ACK

> keep separate build dependancies, not accidentally including files that
> we shouldn't.
> 
>  * src/qemu_*.{c,h} -> src/qemu/
>  * src/xen_unified.{c,h} -> src/xen/xen_driver.{c,h}
>  * src/xend_*, src/xm_* src/xen_*  -> src/xen/
>  * src/test.{c,h} -> src/test/test_driver.{c,h}
>  * src/storage*.{c,h} -> src/storage/
>  * src/security*.{c,h} -> src/security/
>  * src/remote_internal.{c,h} -> src/remote/remote_driver.{c,h}
>  * src/interface_driver.c -> src/interface/netcf_driver.c
>  * src/network_driver.c -> src/network/network_driver.c
>  * src/lxc_* -> src/lxc/
>  * src/openvz_* -> src/openvz/
>  * src/node_device* -> src/nodedev/

  yup sounds fine to me

> That would just leave all the shared source files in src/. We could
> leave them there, or create a src/util/  directory for that stuff.

  I'm fine keeping in the main dir for the moment.

> Move virsh into the tools directory
> 
>  * src/virsh.c -> tools/virsh.c
>  * docs/virsh.pod -> tools/virsh.pod

  Could be left in docs, both places are IMHO adequate

>  * virsh.1:   delete from GIT

  Okay but we need to make sure it's generated for EXTRA_DIST / dist

> Sanitise naming in python/ directory, to make it clear which are the
> manually overriden methods.
> 
>  * python/libvir.c -> python/override-api.c
>  * python/libvir.py -> python/override-api.py
>  * python/libvirt-python-api.xml python/override-api.xml
>  * python/virConnect.py -> python/override-virConnect.py

  okay

>  * python/libvirt_wrap.h -> python/types.h

  the types are wrappers, the problem is that "types.h" is so
generic that it's more likely to raise portability problems,
I would avoid that change

> Cleanup the docs/ directory 
> 
>  * docs/*.html.in   -> docs/website/

  Hum ... I'm not that fond of that, sure it's used for the website
but it's still the main documentation, and I like to have the full docs
tree checkout being the website. If you search the .xml they are on the
web too, at a predictable place.

>  * docs/*.html:   delete from GIT
>  * docs/devhelp:  delete from GIT
>  * docs/html:     delete from GIT

  It's not that much of churn, I don't remember any time where this
generated a problem, and this makes the EXTRA_DIST / dist more complex.
I'm not convinced it will really heklp that much, nor save much
bandwidth either.

>  * docs/libvirt-{api,refs}.xml: delete from GIT

  Disagree, I want those to be in git to see diff, and also to make sure
one can rebuild the python bindings on a platfor where the generation
may fail.

>  * docs/examples/ -> examples/
>  * docs/test*xml -> examples/xml/test/
>  * docs/storage -> examples/xml/storage/

  okay

> Remove include/libvirt/libvirt.h from GIT

  Since the generation of that file is really a direct output of
running configure, okay

> For there places where I list 'delete from GIT', we would ensure that
> when you run 'make dist' the files are still included in the tar.gz

  Yes but still I would prefer to keep some of it in git.

> NB, we would also update the cron job that deploys the website on
> libvirt.org soo that it runs 'make' in the docs/website directory
> to generate the .html files.

  I'm not fond of a subdirectory for the web site. I really think
everything out of doc should be reachable with a trivial http:// url

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
dan...@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to