On Thu, Dec 1, 2011 at 8:44 PM, Jonny Lamb <[email protected]> wrote: > What is this I don't even > ========================= > > Basically, the idea is to throw the following Telepathy components into > one repository (to rule them all):
This is interesting. This is similar how the Linux kernel is organized, however, I want to shed some light into why it works there, and why it might not work here. Also, compare it to Pidgin. So, the advantage of having everything in one big repo is that it's easy to break API and update all the modules, and that's precisely the reason Linux is organized in this way, however, this API is supposed to be *internal*, and that's why out-of-tree modules are not recommended. What Linux kernel developers recommend is to merge *all* modules into the main tree. IOW; out-of-tree modules are expected to break (and they do). I don't think that's what Telepathy is aiming for; the API is supposed to be public, somewhat stable, and usable for out-of-tree modules. Pidgin has a mixture of both big tree, public API, and thus out-of-tree modules. While this helps for internal development, it's not uncommon to see API breaks on external modules because all the internal ones were updated at the same time of the API change, and nobody noticed the backwards compatibility issue until the release has already rolled out. This also doesn't seem ideal. One of the big problems I have with telepathy modules is that I _always_ have to update telepathy-glib, or bunch of other dependencies (similarly int GStreamer). That's not how out-of-tree modules are supposed to work. In an ideal world, Telepathy's API should be backwards compatible, and the modules would not *need* to be updated right away (either telepathy ones, or 3rd party). And when it's updated, you should have an #if condition for the old behavior. So, I could go to telepathy-gabble, and compile it with an old (distributed by Fedora) telepathy-glib. GStreamer has for example GST_DISABLE_DEPRECATED. If I don't define that flag in my external module, I don't *have* to update API, and when I do, I can always add a check for the version of GStreamer to support old systems. Yes, this is extra work, but this ensures that the amount of people able to compile the latest and greatest is maximized, the backwards compatibility of the API is easier to maintain, and it's friendly to external modules. If you go for the single repository, you are basically saying; our API is so unstable that we can't even keep up with it in our own modules, which is not precisely a bad thing IMO, but something to keep in mind. Cheers. -- Felipe Contreras _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
