Re: [libvirt] RFC: Rename / move / delete files in GIT

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.

> > 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.

> > * 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.

> > 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.

> > * 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.

> > 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

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