[Telepathy] One big repository

[Sjoerd Simons]

On Thu, 2011-12-01 at 18:44 +0000, Jonny Lamb wrote:
> 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

This leaves outfor example telepathy-haze and telepathy-rakia for
example. Was this an oversight? If not will they be developed in the
same way as currently or is there some other trick :)

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

You still have to implement it in all these different pieces though so
that won't change. Given that release only one component is already very
tiresome, only imagine the pain if the you try to release all the
modules at the very same time... Instead of having an urgent gabble
release just releasing gabble, you now have to hope tp-qt is in a
releasable state as well :/

> 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!

So if we break the spec we are forced to fix both bindings at the same
time and all the CMs ? I don't see how this makes rapid development
easier really..

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

If any spec breakage implies an ABI break, then this is not so great.

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

If we're going for all configure scripts in the root we will need to
release everything at the same time, which will be a massive pain for us
and for distributions..


In summary i can see some of your benefits, but in general this doesn't
seem to be too well thought out especially when it comes to the
downsides. And just feels like applying one massive hammer to the
problem..

-- 
Sjoerd Simons <sjoerd.simons at collabora.co.uk>
Collabora Ltd.