[Telepathy] Telepathy 1.0 will never happen

[David Laban]

> == Open Questions ==
> 
>  * How long do we use submodules for, or do we force everyone to port all
> of their changes to telepathy-core by hand, right from the first day of
> the project?

Actually git merge works just fine. I ended up using git subtree from 
https://github.com/apenwarr/git-subtree/ to point me in the right direction, 
but I'm pretty sure I could have done it with git merge just as easily if I'd 
found a howto on that first instead. I think that my git-subtree/git-merge(-
Xsubtree=$path)-fu is probably now strong enough to merge any changes that 
happen in parallel with the telepathy-core restructuring.

The repo can be found at http://cgit.collabora.com/git/user/alsuren/telepathy-
core.git (the revision history graph as viewed in gitg is quite pretty). It is 
>22MBs, so I didn't want to put it on fd.o just yet. We can make a graft point 
later if we decide that this is too big.

Can someone provide:

a) Your perfect-world directory structure for telepathy-core if we decide to 
go that way.

b) A good argument for why this (technical) restructuring of repositories is 
actually better than the social thing of saying "This is the telepathy 6.0 
release. It contains tp-glib vX, tp-qt4 vY etc, and conforms to tp-spec vZ"? 
(where X==Y==Z==6.0 is an optional identity) 

(stormer was grilling me today and I couldn't give him a good answer. If this 
is actually the *wrong* solution, I should probably avoid wasting time trying 
to (e.g.) drive CMake from autotools. I will put my efforts on hold for a few 
days, so that we can have a discussion about this.)

>  * I'm not quite sure how the mechanism for breaking the tp-glib-dbus apis
> are supposed to work. Here are a few proposals:
> 
>   1.1 Make each CM author #include <telepathy-glib-dbus-vX/svc-channel.h>,
> and sed *all of their source code* to update from version X to version Y.
> 
>    1.2 Same as above, but if the channel interface hasn't changed between vX
> and vY, generate <telepathy-glib-dbus-vX/svc-channel.h> which
>      #includes <telepathy-glib-dbus-vY/svc-channel.h>.
>      This would avoid too many bullshit sed commits for unchanged files,
> and encourage users to actually check what's changed on a per-file basis
> rather than blindly sedding and hoping for the best.
> 
>   2.1 Let CM authors #include <telepathy-glib-dbus/svc-channel.h> as long as
>     they have defined the macro TP_DBUS_VERSION=X. This would let CM
> writers simply check their code for compat by hand and bump the version
> number to assert that it's all correct in a single header.
> 
>    2.2 Same as the above, but (e.g.) #define tp_svc_channel_interface_* so
> that each function only produces a compiler warning if its semantics has
> been broken between version X and version Y and it is *actually used*
> (more fine-grained than the per-header approach. Does anyone here have the
> macro-fu to do this kind of thing without looking it up?)
> 

This is a technical problem that *does* need to be solved. I don't think we've 
had any objections to the idea of making it easier to break the DBus API, so 
this is something that should happen for sure. The question is how?

Thoughts?

David.