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: [EMAIL PROTECTED] irc: #kde-windows (irc.freenode.net) _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team