[Kde-bindings] Transition to Git and reorganization of kdebindings

[Ian Monroe]

In #kde-bindings, pumphaus, rdale and I (eean) discussed the
transition to Git and the reorganization opportunity this gives us.

The basic problem is that there is difficulty building kdebindings
without kdelibs. Or at least, there is a perception of a problem. I
think anyone subscribed to this list is aware of it, since there have
been a few threads about it. Also to sync with the Qt & KDE release
cycle in a less confusing fashion.

We will split everything by language and library. So eg qtruby and
Korundum will each have its own repo. Each module will then have to be
able to be built indepedently. This will take some cmake tweaking. So
in SVN, kde-bindings/CMakeLists.txt will be just a list of directories
(similar to a parent directory in extragear) and kde-bindings/cmake
will be dispersed. This can be done now just with SVN subdirectories.

So we would have the following repos:
* smokeqt
* smokekde
* smokegen
* qtruby
* korundum
* qyoto
* kimono
* assemblygen (moved from gitorious)
* perlqt
* perlkde (?)
* pykde
* jsmoke (includes qt and kde atm)
* phpqt
* kross (ruby and python in same repo?)

If the layout should look like the above, we will probably have to
write seperate svn2git rulesets for every mentioned project/repo. It's
not really hard since the kde-bindings history is quite linear, but it
will take some additional time. Unfortunately git-filter-branch is not
powerful enough to create the above layout. Because of this
"implementation detail" regarding the svn to git history conversion,
it might make sense to hold off on (commiting) the cmake changes until
after the git conversion.

The Release Team has some say on the timing of this switch. It would
probably make a lot of sense to make the switch Dec 20th, since this
is when 4.6 is branching. This is when pim and plasma are switching to
Git. Dec 20th is only a month away, it might take that long to do the
svn2git rules anyways.

For planning like this its always best to not make the decision in
IRC. So if folks have any questions or objections this is the time &
place. In our discussion the main issue was how much to split up the
repos: by language or by language and qt/kde. The latter was agreed to
just to make a clear 1 tarball/1 repo ratio.

-- Ian, Richard & Arno