Fwd: KDE 4/windows naming

[Patrick Spendrin]

Christian Ehrlicher schrieb:
> I somehow mixed kde-packager and release-team - hope this is now the correct list :)
> 
> 
> 
> ---------------------------8<--------------------
> Hi,
> 
> I'm thinking about a proper naming for the first official KDE4/windows release which should come with KDE4.1 when I'm correct.
> 
> I would propose 'KDE 4.1/windows (alpha)'. Calling it beta would suggest that 4.2 maybe will become stable but I don't think this is possible with the current manpower and the short release cycle (no discussions on the release cycle please - this is another topic).
I am not that amazed of the plan to append the alpha or beta at all but 
this is just my opinion.
> 
> I won't call it beta because we've a lot of internal things to do which most of them aren't directly visible to the user but will affect any KDE program running on windows:
> - the dbus-daemon uses tcp/ip which is a huge security concern. It also doesn't distinguish between system and session,
This is one of the things that probably have to work before we could say 
it is of beta state.
> - the communication between kded, klauncher and others work but I think there're a lot of pitfalls in there where we're not yet aware of (need a wider testing)
> - the system integration for the kcm modules isn't started - I think most of the modules which work on windows should not only affect KDE programs.
What do you mean by this? Should the proxy kcm change the system 
settings proxy stuff as well? Then we'd still have a lot of work to do ...
> - minor: a lot of apps still don't have a proper icon / the icon name changed but nobody adjusted kde4_add_icon() macro :(
I want to have this fixed right before the release - this might add some 
more icons (not sure of that part) and makes sure that no more changes 
are made before the release.
> - Some shared libs are still installed into /lib instead /bin which needs an adjustment of the PATH variable. A normal windows user can't do this.
As we will have to decide about the packages that we {want to|can} 
distribute, this can be fixed for those packages before the release as well.
> - The packaging process (which currently eats most of my time... :( ) needs some improvements to pack each application instead the whole package like it's done now.
This should be a change in the way packaging works - 
kdewin-packager/emerge needs to be able to split up the current targets.
But this leads to another question:
If we're using an approach like that, should we distribute 
win32libs+Qt+kdesupport+kdelibs+kdepimlibs+kdebase-runtime as a KDE 
Runtime Environment / KDE Software Development Kit? We could even split 
that up in a low level part containing win32libs+Qt+kdesupport and a 
high-level part containing only KDE stuff.
The installer would work in the same way as usual but Nullsoft 
Installers should be possible and compatible as well.
> 
> 
> 
> Comments?
> Christian
regards,
Patrick

-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)