[Telepathy] RFC: flattening Telepathy projects into fewer source trees

[Simon McVittie]

As part of Telepathy 1.0 I'm looking into how we can make it easier to
add interfaces to Telepathy, without making a pile of annoyingly
separate releases (somewhat relatedly, see
<https://bugs.freedesktop.org/show_bug.cgi?id=70377> where so far I've
patched telepathy-glib, Mission Control and three separate CMs - and I'm
not finished yet).

One thing that's been suggested several times is merging various
separate source releases. People might have noticed I used coordinated
release names and version numbers for the 0.99.1 and 0.99.2 batches of
releases - this idea is what I was alluding to there.

Possible merges:

telepathy-gabble and telepathy-salut
====================================

This is almost a "no-brainer" - Gabble and Salut use the same library
(Wocky), have very similar implementations in a few places, and speak
variants of the same protocol (XMPP and link-local XMPP). I think they
should be one project, inheriting the higher version number (Gabble's).

Unless people actively veto this, I think I'm going to do this one - but
I'm going to hold off a bit until we've decided how much more merging to
do, because if we want to flatten them both into telepathy-glib, it'll
probably be easier to do that straight away, without merging the two
together first.

telepathy-spec and telepathy-glib
=================================

This is the one that takes us furthest away from Telepathy's
language-agnostic origins[1], and is the one that I most objected to
when this was discussed before, but I've come round to it - I think it's
a necessary pragmatic thing to do. At the moment, introducing a new
stable API and being sure that it's supportable requires all this:

* add it to telepathy-spec as "unstable"
* add it to a CM (or MC, as appropriate) as an "extension"
* implement it in a CM
* add it to some client as an "extension"
* implement a UI for it in that client
* iterate until happy
* mark it as stable in the spec
* do a spec release
* copy the spec release into telepathy-glib
* do a telepathy-glib release
* switch the CM to use the telepathy-glib implementation
* switch the UI to use the telepathy-glib implementation

and in practice we often forget to do the last n stages, leaving it in
some sort of unsupportable limbo (hello
ChannelDispatcher.Interface.Messages, Connection.Interface.Renaming
etc., I'm looking at you).

Alternatively, adding a new stable API with mixins or high-level API
(which we should ideally be doing every time, tbh) requires all this:

* add it to telepathy-spec as "unstable"
* add it to telepathy-glib in a branch that can't be released until
  that spec is
* add it to CM/MC and UI in branches that can't be released until
  that telepathy-glib is
* iterate until happy
* do a spec release
* do a telepathy-glib release
* ... and we can only now merge the CM/MC and UI branches!

Not really any better - there's a lot of "do all these things in
sequence" and it's a lot of work. Even for people who've been hacking on
Telepathy for 5 years, it's frustrating; for new contributors, the
practical effect is more like "give up now", which is the last thing we
want.

If we flatten the spec into telepathy-glib, we can reduce that to:

* add it to telepathy-(spec|glib) in a branch that can't be merged
  until we're happy with it
* add it to CM/MC and UI in branches that can't be released until
  that telepathy-(spec|glib) is
* iterate until happy
* do a telepathy-(spec|glib) release
* merge the CM/MC and UI branches

which is already considerably better. See below for further flattening
which streamlines this further.

Because we have pretty good support for gobject-introspection in
telepathy-glib, we don't actually necessarily need to branch things like
Empathy to prove that an API is "good enough" - we can knock together a
sketchy UI in Python or JavaScript and put it in telepathy-glib's
examples directory. That helps streamline the process.

telepathy-glib and misc single-implementation things
====================================================

One of the major components where it's good to be able to add new APIs
is telepathy-mission-control. There is only one implementation, it's
written in C using GLib, and there's enough code and enough subtlety in
it that I don't think anyone will reimplement it (at least, not
correctly); so we might as well fold it into telepathy-glib. We could
have a --without-mission-control option if anyone cares.

telepathy-logger is another obvious candidate for squashing into
telepathy-glib: there's only one implementation (its Qt binding is a
binding/wrapper, not a reimplementation) and it's in C with GLib.

Similarly, telepathy-farstream is actually pretty small, and now that
we've gone over the GStreamer 0 -> GStreamer 1 speed-bump, it should be
pretty stable. This one will definitely need a --with[out]-farstream option.

telepathy-glib and "major" connection managers
==============================================

I'm in two minds about this one. Flattening at least the most major GLib
CMs (Gabble, Salut, Haze, maybe Rakia, maybe Idle) into telepathy-glib
would make it much easier to prove that new APIs are "good enough". If
we're using gobject-introspection to rapid-prototype UIs, we could
potentially even do the entire "add a feature, iterate on the API, make
it good enough, merge it" cycle within a telepathy-glib branch, which
would be superb.

On the other hand, the GLib CMs are quite different internally, and
aren't necessarily going to get contributions from the same people, so
I'm not sure about this one...

One possible compromise would be creating a
telepathy-connection-managers source tree, but I don't think that really
helps - you still have to branch an extra thing, and build it against
your branch of telepathy-glib.

telepathy-glib and Telepathy-Qt
===============================

This is one merge that I'm *not* proposing to do, at least not now.
Telepathy-Qt has (de facto) distinct maintainers, a different release
schedule, a different base library and a different build-system, so I
don't really think merging it into the "one big tree" is viable.

This does raise the possibility that Telepathy-Qt will get out of date
compared with telepathy-glib. My opinion is that we just have to live
with that. Having a separate branch for Telepathy-Qt, whose spec lags
behind a little, isn't *so* bad: telepathy-glib is enough to verify that
APIs are implementable and can have decent high-level API, which is the
most contentious stage of adding new APIs.

-----------------------------

[1] actually, telepathy-spec and telepathy-python used to be the same
project, if you go back far enough...