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

[Simon McVittie]

On 04/12/13 17:01, David Edmundson wrote:
>> And if everything is in sync, this also means that the spec can become a
>> private API, so we don't have to care so much or keep it stable.
> 
> If you do this and TpQt remains out of tree, that will screw us over
> completely.

I don't intend to go that far. I still think there's value in having
D-Bus APIs that are external API, as long as we have enough agility to
keep improving them. Being able to review and merge a branch that
implements a new D-Bus API "across the board" in one operation will help
a lot with that, I think.

My goal for the D-Bus API would be more like:

* nothing breaks in a stable branch of Telepathy (currently
  once every ~ 6 months, approximately aligned with GNOME/Fedora/Ubuntu;
  but if you want to adjust stable branch timings so they align
  better with KDE/other distros, please ask)

* "core" interfaces break infrequently (lifetime of multiple years)

* existing interfaces might break occasionally if their design turns
  out to be holding us back (lifetime of a couple of years?)

* new/sketchy interfaces on a development branch could break frequently
  (lifetime measured in days or weeks) until their design solidifies

where by "break" I mean the number in the interface's name changes, so
from Telepathy-Qt's perspective it behaves like a new interface with
similar functionality.

If necessary, client code can look for more than one interface version
and hide the differences (where feasible), or CM code can even implement
more than one interface version simultaneously (although we'll be
reluctant to do that too often).

To work with current CMs at the time, Telepathy-Qt will need to keep up
- it'd probably be wise to have a target Telepathy version in mind, and
stable-branch Telepathy-Qt at about the same time as "the big Telepathy
tree" - but that's already been the case for things like StreamedMedia
-> Call, Text -> Messages, SASLAuthentication, and Chan.Type.ContactList
-> Conn.I.ContactList anyway.

If Telepathy-Qt falls behind, the typical failure mode would look like
"I can no longer see avatars in KDE, because Telepathy-Qt implements
Connection.Interface.Avatars3 and the connection managers only have
Connection.Interface.Avatars4" (or substitute some other feature for
avatars). The "nothing works" case would only be across major,
all-of-Telepathy API breaks, like the one we're currently trying to do
from Telepathy 0 to Telepathy 1 - I hope not to have to do another major
break like this for a few years.

    S