[Telepathy] One big repository

[George Kiagiadakis]

On Thu, Dec 1, 2011 at 8:44 PM, Jonny Lamb <jonny.lamb at collabora.co.uk> wrote:
> Basically, the idea is to throw the following Telepathy components into
> one repository (to rule them all):

I would advise you to think again before doing that.

> One of the problems at the moment is that if you make a spec change (add
> an interface, perhaps), you have to implement it in spec, then perhaps
> in the CM or mission-control, and then you have to play with
> telepathy-glib to get the code generation (at the very least) going.
> After all this, you have to make a spec release, tp-glib release, and
> gabble release (in that order). It's all rather boring.

I understand your point, but I don't think this will be any better if
you have everything in one repository. You will still have to go edit
the spec first, then hack on tp-glib, then on tp-gabble, then hack on
tp-qt4 as well, and finally after modifying everything, merge in
master. It is still a big task to do, or rather a bigger task, because
whoever makes a spec change will need to make sure that everything
else in the repository still works.

> The other big advantage of this is that we can break the D-Bus spec
> easily because the other components (notably tp-glib and tp-qt4) will
> (hopefully) continue to be in sync. There are lots of spec breakages on
> the cards to remove deprecated stuff and to make interfaces less silly.
> A personal favourite will be the org.freedesktop.Telepathy →
> im.telepathy rename!
>
> The point of doing these breaks in a big repository is that we can make
> the spec breakages and fixes atomic. If you are an app using Telepathy
> (using tp-glib or tp-qt4) I *hope* there won't be any changes to your
> code and even no re-compilation required at all as it'll only be the
> helper library that actually changes.

You can still break the spec having separate repositories. When the
breakage affects applications, the consequences will be the same. When
the breakage affects only the libraries, you just need to make sure
they are fixed and released together (perhaps with the same version
number too?) and the problem is solved. Having a common repository is
little benefit imho. In tp-kde we have 12 components in 12
repositories (and growing...), all tied together and released
together. It's not a problem.

And btw, since tp-glib/tp-qt4 clients are supposed to just use the
high level APIs and have no or minimal impact from spec breakages, why
gabble, salut, m-c & logger have to be in this repository. Since they
are supposed to use the high level APIs of tp-glib, should they be
tied to spec changes?

> However, saying that, we're also going to take this opportunity to start
> breaking API & ABI in at least telepathy-glib. (Andre has already told
> me that because the tp-qt4 guys are doing lots of changes soon to start
> supporting Qt5 and a rename from tp-qt4 → tp-qt, it should be left out
> for now. This is kind of useful as it is the most different component
> (not GLib, uses CMake, etc.))

Breaking API & ABI will introduce trouble anyway, and doing this in a
unified repository will be a PITA. Suppose you remove an interface
from the spec and then break tp-glib's and tp-qt4's APIs to reflect
this change, but there are still applications using the old API, so
you make a branch with the old version to keep supporting them. Then
at the same time tp-qt4 branches to tp-qt5, but hey, we still need to
support both versions because qt4 isn't going anywhere yet, and at the
same time for example we have farstream doing some changes to support
gst 1.0 (i.e. more branches), so we need to have a gazillion branches
around with all possible combinations. This will be a total mess. Who
is going to deal with it? Ok, I'm exaggerating a bit here (using kind
of void examples), but my point is that since those libraries are of
very different nature, such problems can arise.

Another problem with the big repository, imho, is that it discourages
wider adoption and contribution. In the Qt/KDE world we have been
living years with monolithic repositories and we've all learned our
lesson by now that monolithic repositories are no good (hence the
reason that both Qt and KDE are splitting everything atm). What
happens is that people are not very willing to be bothered with other
parts of the repository when they just use or work on a specific
component and in many cases they are much more willing to fork rather
than play by the rules. That's simply because being bothered by other
parts of the repository and aligning release schedules makes life
harder. I've seen this happening in the past with parts of KDE and I
don't want to continue seing it. It's very disapointing and
discouraging for everybody.

So, my counter-proposal is this: Keep the split repositories, break
the spec for good now, break API & ABI in all the affected libraries,
make the CMs and MC independent from the spec if needed (move any
spec-specific parts in tp-glib), bump all libraries to version 1.0 and
start releasing them together when it makes sense. So, when there is
some spec change that needs all libraries to be in sync, release a new
1.x version of all the libraries together, and at the same time allow
libraries independently to do bug fixes or api enhancments in 1.x.y
releases.

>
> Build system
> ------------
> So, it sounds like we're going to have to push all the configure scripts
> for each component up into a big top-level one, no?
>
> Also, Will was promoting non-recursive automake. Thoughts?
>
> So, any other ideas about this? I already know people want
> --disable-bonghits or whatever. In a way, I guess there aren't many
> choices here but I thought I'd ask around before committing to big
> changes.

As already mentioned in previous emails, tp-qt4 uses cmake and I also
don't think it would be acceptable to go back to autotools. The other
way around (switching everything to cmake) would be possible of course
(and has advantages too), but I fear I might end up murdered by ninjas
in my sleep if I dare to propose it seriously :P

Regards,
George