On T= hu, Feb 5, 2015 at 11:33 PM, Albert Astals Cid <aacid@kde.org> w= rote:

El Dijous, 5 de febrer de 2015, a l= es 21:24:10, Sune Vuorela va escriure:

> On 2015-02-02, Martin Klapetek <martin.klapetek@gmail.com> wrote: > > Another part that KDE Telepathy needs is KAccounts and we'd l= ike
> > to move that one too, probably to kde-runtime but there seems to = be
> > some disagreements of the purpose of kde-runtime. KAccounts is >
> I'm pretty sure that everything in kde-runtime is only for kdelibs= . in
> Frameworks, everything has been moved into the framework it is a part<= br> > of.
>
> KAccounts sounds mostly like a network thing to me, at least so far. I= f
> it becomes more than a network accounts thing, maybe it should become = a
> framework ?
>
> > [1] KDE Telepathy repos are:
> >=C2=A0 ktp-accounts-kcm
> >=C2=A0 ktp-approver
> >=C2=A0 ktp-auth-handler
> >=C2=A0 ktp-call-ui*
> >=C2=A0 ktp-common-internals
> >=C2=A0 ktp-contact-list
> >=C2=A0 ktp-contact-runner
> >=C2=A0 ktp-desktop-applets
> >=C2=A0 ktp-filetransfer-handler
> >=C2=A0 ktp-kded-module
> >=C2=A0 ktp-send-file
> >=C2=A0 ktp-text-ui
>
> would this also be a time to maybe reconsider if one went a bit
> overboard with the original repository splitting?=C2=A0 Having a
> libkdetelepathyinternalsprivate as a *public* available library someho= w
> smells like a bit wrong to me.

+1 all that many ktp repositories always seemed more a hassle t= han a benefit
to me. What's the benefit of such high granularity?

As responded to Sune, this follow the upstream philosophy/= hierarchy. And

also what frameworks does. Each of these component= s can work fully standalone

(just with ktp-common-internals) and = allows anyone to take that component

without dragging all 200k LO= C, much of they don't need.

I don't think = it's a hassle really...possibly for packagers, I could see that.

<= div>But as a developer...all you need is kdesrc-build, releasing is also sc= ripted...