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

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/