[Kde-scm-interest] Splitting kdebindings when moving to git

[Ian Monroe]

On Thu, Aug 19, 2010 at 10:02 AM, Arno Rehn <kde at arnorehn.de> wrote:
> Hi again,
>
> I know that splitting the monolithic KDE modules into different git-repos has
> been discussed a thousand times here and that you're probably pretty much fed
> up with it. However I have to bring it up again:
>
> With KDE bindings we have the problem that many people only want the Qt-
> specific part of the bindings (like QtRuby or Qyoto) - and then only for one
> language. Having all of the different bindings in a KDE module makes it
> difficult for them to install only the Qt portion and even prevents some
> people from contributing (there's already a fork of QtRuby on github, because
> people don't like checking out the complete kdebindings and then going through
> the hassle of figuring out how to compile only QtRuby).
>
> Would it be possible to have some of the bindings in a seperate repository,
> either under a 'kdebindings' umbrella or - maybe even better - in kdesupport?
>
> We could then also coordinate Qt-bindings releases with the Qt releases, which
> is obviously very important for bindings and doesn't work too well if the
> bindings are released every half a year with the rest of KDE.
>
> Thanks in advance and sorry for bringing that topic up again,

If you go look at http://git.kde.org now you can see that it is
possible to define hierarchies of separate repos, at least for the web
interface.

(And maybe this is more of a discussion for the kdebindings list.) The
downside of splitting up a repo is that its more difficult to make a
change in several repos at once. Like I can imagine a change in
libsmoke breaking some bindings and the person who made the change
didn't even realize it since they didn't have it all checked out.