Fwd: KDE 4/windows naming

[Christian Ehrlicher]

Patrick Spendrin schrieb:
> 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.
Not adding anything would mean that it's full useable which is not the 
case (we're imho far away from this)

>>
>> 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 ...
At least in the long term - you can't explain anyone why he has to add 
proxy settings twice etc.

>> - 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.
This sounds much easier than it is - do you have the time to fix it? I 
guess not.

> 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.
I think three parts - win32libs (or 'support' libs), Qt and KDE SDK 
(support, libs, pimlibs) - should be ok.

> The installer would work in the same way as usual but Nullsoft 
> Installers should be possible and compatible as well.
This is already possible.


Christian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/release-team/attachments/20080521/51ebd6ee/attachment.pgp