[Telepathy] RFC: flattening Telepathy projects into fewer source trees
David Edmundson
david at davidedmundson.co.uk
Mon Oct 21 11:33:48 PDT 2013
I don't fully understand the reason behind the problem you are having
with having to release the spec, then release glib and only then merge
the dev branches in each CM.
Why can't you just merge every dev branch at the same time and release
all the repositories all at the same time? It would have the same
drawbacks as having everything in the same repository.
It seems very backwards from the current trend of libraries which is
to split things. In KDE in particular we already have > 100 git
repositories all being tagged at the same time. Our libraries which
are all interconnected and share releases are about to be split into
25 or so different repositories. It's a problem that we solve with
tools to build many repositories all at once (kdesrc-build) and
release scripts. Telepathy is of the annoying size to be too small to
have tools to do this but slightly too large to manage by hand.
More specific comments below.
>telepathy-gabble and telepathy-salut
Makes sense, fine with me.
> telepathy-spec and telepathy-glib
I don't like the "glib is important, Qt is a second class citizen"
mentality. Granted that does reflect the current situation, but I
don't want it being constrained to being like this forever.
> telepathy-glib and misc single-implementation things
Logger + glib I'm OK with.
Farstream I'm not so convinced about, TelepathyQt uses
TelepathyFarstream but it does not use TelepathyGlib.
Not needing glib is one of the nice things about the way telepathy
libraries work. Once you merge repositories even if it remains a
separate library, packagers will still be annoying about it all.
I'm not in favour of this, but I wouldn't object either.
>telepathy-glib and "major" connection managers
I don't think this is a good idea.
It makes some connection manager's appear more important than others.
It becomes very hard to ever replace a connection manager (and we have
dropped sunshine and butterfly in the past) as you end up with a
connection manager in the main repo that everyone has to build (or
packagers will build at least) as well as something newer.
We used to have this when KDE had giant multi-application repositories
and it's why we ended up splitting.
I am against this.
>telepathy-glib and Telepathy-Qt
I don't want this either.
Whilst we're on the subject of repositories, telepathy-logger-qt is
inside KDE repositories and not on Freedesktop.org. This makes little
sense, and is something I'd like to fix.
Maybe I should merge TpQt if you go that way with logger+TpGlib.
Regards
David
More information about the telepathy
mailing list