[Telepathy] One big repository

Jonny Lamb jonny.lamb at collabora.co.uk
Thu Dec 1 10:44:28 PST 2011


Email is way too hard for me.

What is this I don't even
=========================

Basically, the idea is to throw the following Telepathy components into
one repository (to rule them all):

 * farstream
 * gabble
 * glib
 * logger
 * mission-control
 * qt4
 * salut
 * spec
 * yell

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.

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.

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.))

So yeah, soon we'll be breaking some API & ABI in tp-glib. Exactly what
yet has not been decided and in a way it doesn't matter.

The repository
==============

So I started playing with this multiple repository thing and created
this:

    http://cgit.freedesktop.org/~jonny/telepathy/

*THIS IS JUST A TEST REPOSITORY, DON'T BOTHER CLONING IT OR USING IT*

I tried to retain as much history from the original repositories as
possible but updating existing patches for the new repository will need
some attention (rebasing, epic sad face). I started doing a bit of work
to see how easy it would be to make tp-glib stop shipping its own spec
directory, as you can see. I think it's okay but will take a bit of time
playing around. I didn't want to do too much with this because it's
still only a playground repository (and it even contains tp-qt4). I'm
also going to have to freeze all the other repositories so no-one starts
pushing stuff "upstream" to the wrong place.

Open questions
==============

Build system
------------

At the moment, in this test repository, things are starting to get
better by not using their own copy of the spec and using upstream
instead, but stuff like distcheck won't work at all because I've not
told tp-glib to distribute with a copy of the spec.

Basically, how do people think the build system should work? I
originally thought it'd be neat to be able to:

% cd telepathy/gabble
% ./configure
% make

but in reality this isn't possible because gabble depends on tp-glib and
yell, and these will need to be built before gabble itself.

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.

Wocky
-----

Both salut and gabble use wocky. This whole single repository thing is
nothing to do with Wocky and currently it's not to do with merging
gabble and salut, so I'm tempted to just leave gabble and salut with
having their own Wocky submodules. Does that sound reasonable?

In conclusion
=============

This email is not about what we could break inside Telepathy. It's just
about the repository logistics.

I think this turned into more of a braindump than a concise email; sorry
about that.

Slatez,

-- 
Jonny Lamb



More information about the telepathy mailing list