<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 28, 2014 at 7:10 PM, Kevin Ottens <span dir="ltr"><<a href="mailto:ervin@kde.org" target="_blank">ervin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
</div>I don't think we'll get a one size fit all type of solution, that will heavily<br>
depend on the nature of the framework. For instance something like KConfig<br>
should probably provide it's own imports, it is in the natural order of things<br>
as it already provides a core/gui split. KIO is in pretty much the same<br>
situation.<br>
<br>
But for some others it is less clear... For those ones we'll have to decide if<br>
we want to change them toward providing several payloads as well (sounds<br>
doable for most except the *addons ones), or if we want the import to be in<br>
one of the imports provided by KDeclarative.<br></blockquote><div><br></div><div>One of the downsides that wasn't mentioned yet (I think) is keeping the imports away from their modules can (and possibly will) cause the imports to bitrot and get behind the modules. Say that someone makes some changes to the framework but forgets/doesn't know about imports in KDeclarative, so those stay unupdated and may even break. Can also lead to "not my problem" situation when the KDeclarative maintainer will say "that's code from kio, talk to kio maintainer" etc.</div>

<div><br></div><div>So I think it makes sense to keep the code together.</div><div><br></div><div>Cheers</div></div>-- <br><div><span style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></div>
</div></div>