On Thu, Dec 1, 2011 at 8:44 PM, Jonny Lamb <[email protected]> wrote: > Basically, the idea is to throw the following Telepathy components into > one repository (to rule them all):
I would advise you to think again before doing that. > 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. I understand your point, but I don't think this will be any better if you have everything in one repository. You will still have to go edit the spec first, then hack on tp-glib, then on tp-gabble, then hack on tp-qt4 as well, and finally after modifying everything, merge in master. It is still a big task to do, or rather a bigger task, because whoever makes a spec change will need to make sure that everything else in the repository still works. > 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! > > 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. You can still break the spec having separate repositories. When the breakage affects applications, the consequences will be the same. When the breakage affects only the libraries, you just need to make sure they are fixed and released together (perhaps with the same version number too?) and the problem is solved. Having a common repository is little benefit imho. In tp-kde we have 12 components in 12 repositories (and growing...), all tied together and released together. It's not a problem. And btw, since tp-glib/tp-qt4 clients are supposed to just use the high level APIs and have no or minimal impact from spec breakages, why gabble, salut, m-c & logger have to be in this repository. Since they are supposed to use the high level APIs of tp-glib, should they be tied to spec changes? > 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.)) Breaking API & ABI will introduce trouble anyway, and doing this in a unified repository will be a PITA. Suppose you remove an interface from the spec and then break tp-glib's and tp-qt4's APIs to reflect this change, but there are still applications using the old API, so you make a branch with the old version to keep supporting them. Then at the same time tp-qt4 branches to tp-qt5, but hey, we still need to support both versions because qt4 isn't going anywhere yet, and at the same time for example we have farstream doing some changes to support gst 1.0 (i.e. more branches), so we need to have a gazillion branches around with all possible combinations. This will be a total mess. Who is going to deal with it? Ok, I'm exaggerating a bit here (using kind of void examples), but my point is that since those libraries are of very different nature, such problems can arise. Another problem with the big repository, imho, is that it discourages wider adoption and contribution. In the Qt/KDE world we have been living years with monolithic repositories and we've all learned our lesson by now that monolithic repositories are no good (hence the reason that both Qt and KDE are splitting everything atm). What happens is that people are not very willing to be bothered with other parts of the repository when they just use or work on a specific component and in many cases they are much more willing to fork rather than play by the rules. That's simply because being bothered by other parts of the repository and aligning release schedules makes life harder. I've seen this happening in the past with parts of KDE and I don't want to continue seing it. It's very disapointing and discouraging for everybody. So, my counter-proposal is this: Keep the split repositories, break the spec for good now, break API & ABI in all the affected libraries, make the CMs and MC independent from the spec if needed (move any spec-specific parts in tp-glib), bump all libraries to version 1.0 and start releasing them together when it makes sense. So, when there is some spec change that needs all libraries to be in sync, release a new 1.x version of all the libraries together, and at the same time allow libraries independently to do bug fixes or api enhancments in 1.x.y releases. > > Build system > ------------ > 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. As already mentioned in previous emails, tp-qt4 uses cmake and I also don't think it would be acceptable to go back to autotools. The other way around (switching everything to cmake) would be possible of course (and has advantages too), but I fear I might end up murdered by ninjas in my sleep if I dare to propose it seriously :P Regards, George _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
