On Tue, Sep 15, 2009 at 03:18:41PM +0100, Daniel P. Berrange wrote:
On Tue, Sep 15, 2009 at 03:36:13PM +0200, Daniel Veillard wrote:
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
Ok, paulo suggested that too, so i'll go for that instead.
thanks !
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
I think its important to have the POD docs in the same place as the source file, mostly so its obvious that people changing the virsh.c will see there's a man page that needs changing too.
Okay, good point, didn't think about this
* 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
Ok, I'll think of a name that's less likely to clash - just wanted the .c and .h to have the same base name here.
okay
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.
Mostly just that it is rather a pain to have these files creating huge changesets when doing API work. Or changing sitemap.html.in for example results in a giant changeset affecting every html file which is obscuring the real change when doing reviews.
It's true that adding a single entry update them all
* 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.
The API generator should really ever fail on other OS, since it is pure python + libxml2 both of which are pretty reliable & portable.
Failure to build is only a small part of my attachment to keeping it in git, it's the fact that change to libvirt-api.xml are really indicative of interface changes, and I really like them recorded and be able to spot changes immediately on git diff/status I don't really care about -refs that's really glue, but -api is a primary resource for me, even if it's generated in some ways (not systematic).
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
The goal was to try and make it clear what's part of the website and what's not - eg some bits under docs/ are not part of the website. I will try a different approach though, leave the website where it is and see if any of the other bits are better elsewhere. eg pki_check.sh might be better as tools/virt-pki-check
Okay, what about having the .html.in in a website subtree but the generated output in docs/ so that docs/ subtree is what is available via HTTP ?
FYI, i'll have a go at making these changes and make them visible as a branch on my gitorious.org repository so other people can see what it all looks like
okay, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/