Splitting out core and bindings final stages

[John (J5) Palmieri]

So a bit of a status update.  With the help of Carl Worth I have been
able to put together a series of scripts for importing d-bus into git
and splitting out the bindings into separate repositories while
maintaining history.

NOTE: for the time being the dbus core libraries will continue to be
worked on in CVS and the bindings in git once the move happens.  The
core, along with its history will also be in git and if we ever decide
to move it we can import again from CVS and not duplicate the history.

Caveats with the split:

* Tests in the /dbus/tests have not been figured into the port. History
is not as important (and would be preserved in the core repository
anyway) so rechecking them in would be the easiest.  If you feel it is
important for your module I can reconsider.

* ChangeLog is not being preserved.  This is because the patch sets do
not apply correctly when just considering the bindings.  I can build the
ChangeLog from the patch set but the work involved is not worth it
considering git renders ChangeLogs useless and if you have been
following procedure your CVS commit messages should simply be a copy of
the ChangeLog.  In the future the ChangeLog in tarballs will be
generated using git-log.

* Tags and Branches, while being preserved in the initial import (i.e.
core repository), splitting out the bindings to separate repositories
loses this information.  If someone wants they can write a script to
reapply them or do them by hand.  Again, it is more work than we gain
because the history will be preserved in the core repository and the
bindings are pretty much useless without the core prior to the split.

The Plan:

There are two ways to access git (anon and ssh) on fd.o.  I will use the
ssh server to describe the layout of the repositories.  For more
information on using git with fd.o servers refer to the wiki page
http://freedesktop.org/wiki/UsingGit.

The D-Bus repository layout -

The core repository where we will have the initial import will be at 
git+ssh://git.freedesktop.org/git/dbus/dbus-core

The bindings will be found at 
git+ssh://git.freedesktop.org/git/dbus/bindings/dbus-<binding name>

Bindings being moved to new repositories:
- python
- glib
- qt
- qt3
- mono

Bindings being removed completely:
- gcj

Bindings we are adding:
- None at this time.  We need to write up rules for inclusion.

The initial import and split-

I have been doing tests and am reasonably happy with the results.  I am
going to create a local repository, split out the bindings without any
modifications and post it to a website this weekend where module owners
can pull their repo, play with it and confirm everything was preserved.

Once the module owners have gotten back to me (someone want to take on
Mono and Qt3?) I will put a freeze on modifications to the bindings in
CVS (core will remain open).  In this time I will do 1 more cvs-import
and break out the bindings like before.  Once I do that I will push the
repos to fd.o.

The last mile-

I expect it to take about a day or so.  At this point the maintainers
and contributors should descend on all of the modules (I will take
python) and create build environments and test suites (make check) for
them.  Once that is done and the bindings stripped out of CVS I will
build a 0.90 release of dbus which everyone should build a release of
their bindings off of (feel free to version them how you see fit).  This
will mark the last synchronous release of the core and bindings (until
such a time that synchronous releases make sense again).

Someone will also need to update the Wiki.

Moving forward:

An external test suite would be great. I will continue checking releases
against the Glib and Python bindings but it would be great to have a
script that got all the latest sources, built them and then ran cross
binding tests.

Some commit rules for git:

- make sure you set GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL in your
environment
- No need to make ChangeLog entries because git will timestamp your name
and email along with your commit comments
- commit comments should just include the comments, timestamp and start
from the first column. i.e.:

* python/Makefile.am: Fixed build for the split

* configure.in: Created build environment

-- 
John (J5) Palmieri <johnp at redhat.com>