[Telepathy] One big repository

[Felipe Contreras]

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

This is interesting. This is similar how the Linux kernel is
organized, however, I want to shed some light into why it works there,
and why it might not work here. Also, compare it to Pidgin.

So, the advantage of having everything in one big repo is that it's
easy to break API and update all the modules, and that's precisely the
reason Linux is organized in this way, however, this API is supposed
to be *internal*, and that's why out-of-tree modules are not
recommended. What Linux kernel developers recommend is to merge *all*
modules into the main tree. IOW; out-of-tree modules are expected to
break (and they do).

I don't think that's what Telepathy is aiming for; the API is supposed
to be public, somewhat stable, and usable for out-of-tree modules.

Pidgin has a mixture of both big tree, public API, and thus
out-of-tree modules. While this helps for internal development, it's
not uncommon to see API breaks on external modules because all the
internal ones were updated at the same time of the API change, and
nobody noticed the backwards compatibility issue until the release has
already rolled out.

This also doesn't seem ideal.

One of the big problems I have with telepathy modules is that I
_always_ have to update telepathy-glib, or bunch of other dependencies
(similarly int GStreamer). That's not how out-of-tree modules are
supposed to work.

In an ideal world, Telepathy's API should be backwards compatible, and
the modules would not *need* to be updated right away (either
telepathy ones, or 3rd party). And when it's updated, you should have
an #if condition for the old behavior. So, I could go to
telepathy-gabble, and compile it with an old (distributed by Fedora)
telepathy-glib.

GStreamer has for example GST_DISABLE_DEPRECATED. If I don't define
that flag in my external module, I don't *have* to update API, and
when I do, I can always add a check for the version of GStreamer to
support old systems.

Yes, this is extra work, but this ensures that the amount of people
able to compile the latest and greatest is maximized, the backwards
compatibility of the API is easier to maintain, and it's friendly to
external modules.

If you go for the single repository, you are basically saying; our API
is so unstable that we can't even keep up with it in our own modules,
which is not precisely a bad thing IMO, but something to keep in mind.

Cheers.

-- 
Felipe Contreras