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... _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy