[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Moving KDE Telepathy to kdenetwork
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2015-02-06 10:46:08
Message-ID: CAPLgePpru4kFw2t0D1FTY3Uycknc+-KVviBjurRftot5MtQ5kw () mail ! gmail ! com
[Download RAW message or body]
On Thu, Feb 5, 2015 at 11:33 PM, Albert Astals Cid <aacid@kde.org> wrote:
> El Dijous, 5 de febrer de 2015, a les 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 like
> > > 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
> > of.
> >
> > KAccounts sounds mostly like a network thing to me, at least so far. If
> > it becomes more than a network accounts thing, maybe it should become a
> > framework ?
> >
> > > [1] KDE Telepathy repos are:
> > > ktp-accounts-kcm
> > > ktp-approver
> > > ktp-auth-handler
> > > ktp-call-ui*
> > > ktp-common-internals
> > > ktp-contact-list
> > > ktp-contact-runner
> > > ktp-desktop-applets
> > > ktp-filetransfer-handler
> > > ktp-kded-module
> > > ktp-send-file
> > > ktp-text-ui
> >
> > would this also be a time to maybe reconsider if one went a bit
> > overboard with the original repository splitting? Having a
> > libkdetelepathyinternalsprivate as a *public* available library somehow
> > smells like a bit wrong to me.
>
> +1 all that many ktp repositories always seemed more a hassle than 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 components can work fully
standalone
(just with ktp-common-internals) and allows anyone to take that component
without dragging all 200k LOC, much of they don't need.
I don't think it's a hassle really...possibly for packagers, I could see
that.
But as a developer...all you need is kdesrc-build, releasing is also
scripted...
Cheers
--
Martin Klapetek | KDE Developer
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 5, 2015 \
at 11:33 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" \
target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">El Dijous, 5 de febrer de 2015, a les 21:24:10, Sune Vuorela \
va escriure:<br> <div><div class="h5">> On 2015-02-02, Martin Klapetek <<a \
href="mailto:martin.klapetek@gmail.com">martin.klapetek@gmail.com</a>> wrote:<br> \
> > Another part that KDE Telepathy needs is KAccounts and we'd like<br> \
> > to move that one too, probably to kde-runtime but there seems to be<br> \
> > some disagreements of the purpose of kde-runtime. KAccounts is<br> ><br>
> I'm pretty sure that everything in kde-runtime is only for kdelibs. in<br>
> Frameworks, everything has been moved into the framework it is a part<br>
> of.<br>
><br>
> KAccounts sounds mostly like a network thing to me, at least so far. If<br>
> it becomes more than a network accounts thing, maybe it should become a<br>
> framework ?<br>
><br>
> > [1] KDE Telepathy repos are:<br>
> > ktp-accounts-kcm<br>
> > ktp-approver<br>
> > ktp-auth-handler<br>
> > ktp-call-ui*<br>
> > ktp-common-internals<br>
> > ktp-contact-list<br>
> > ktp-contact-runner<br>
> > ktp-desktop-applets<br>
> > ktp-filetransfer-handler<br>
> > ktp-kded-module<br>
> > ktp-send-file<br>
> > ktp-text-ui<br>
><br>
> would this also be a time to maybe reconsider if one went a bit<br>
> overboard with the original repository splitting? Having a<br>
> libkdetelepathyinternalsprivate as a *public* available library somehow<br>
> smells like a bit wrong to me.<br>
<br>
</div></div>+1 all that many ktp repositories always seemed more a hassle than a \
benefit<br> to me. What's the benefit of such high \
granularity?<br></blockquote><div><br></div><div>As responded to Sune, this follow \
the upstream philosophy/hierarchy. And</div><div>also what frameworks does. Each of \
these components can work fully standalone</div><div>(just with ktp-common-internals) \
and allows anyone to take that component</div><div>without dragging all 200k LOC, \
much of they don't need.</div><div><br></div><div>I don't think it's a \
hassle really...possibly for packagers, I could see that.</div><div>But as a \
developer...all you need is kdesrc-build, releasing is also \
scripted...</div></div><div><br></div><div>Cheers<br></div>-- <br><div \
class="gmail_signature"><div><span style="color:rgb(102,102,102)">Martin Klapetek | \
KDE Developer</span></div></div> </div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic