Why is KConfig tier2?

[Alexander Neundorf]

On Saturday 22 June 2013, Aleix Pol wrote:
> On Sat, Jun 22, 2013 at 1:17 PM, David Faure <faure at kde.org> wrote:
> > Le samedi 22 juin 2013 13:03:22 Aleix Pol a écrit :
> > > Hi,
> > > We've been looking through some code scratching our heads on how we can
> > 
> > do
> > 
> > > it to workaround uses of KConfig because of it being tier2.
> > > 
> > > Then we decided to look at it and we saw that KConfigCore and
> > > KConfigGui only seems to depend on Qt.
> > > 
> > > So, maybe it could be moved to tier1?
> > 
> > Yes, it's tier1 now, since I put QLockFile in Qt.
> > 
> > (It was using kcoreaddons before, for KLockFile).
> > 
> > Back then I thought "let's not move it, all this will move again anyway",
> > but
> > clearly it's confusing people, so yes, please move it :-)
> > 
> > --
> > David Faure, faure at kde.org, http://www.davidfaure.fr
> > Working on KDE, in particular KDE Frameworks 5
> 
> Ok, so yes, it's misleading to have it in tier2. Or well, are tiers
> documented anywhere? We've been looking for it too and haven't found
> anything yet.

kconfig is still in tier2/.
As far as I see, it depends on:
- Qt
- e-c-m
- kdeqt5staging
- KDEWin

So, should it be moved ?
Is this simply
git mv tier2/kconfig tier1/ ?


Beside that, is anybody using Windows working on frameworks ? IIRC the plan 
for KDEWin was to get rid of it, right ? We also still need the XP manifest 
stuff for add_executable() AFAIK.

Alex