#*Could we have release versions with debug information? On msvc, this could help to achieve the goal mentioned in the above point while it is still possible to link release binaries with and without debug information.

#*Could we have release versions with debug information? On msvc, this could help to achieve the goal mentioned in the above point while it is still possible to link release binaries with and without debug information.

#reducing distribution of the file by keeping a snapshot of files on our

#reducing distribution of the file by keeping a snapshot of files on our

−

#dbus for win32 is working mostly for recent kde applications, although there are some issues:

#dbus for win32 is working mostly for recent kde applications, although there are some issues:

#*A service registered in dbus is not removed in case the related application crashes. This was detected with klauncher on msvc.

#*A service registered in dbus is not removed in case the related application crashes. This was detected with klauncher on msvc.

Revision as of 12:40, 16 September 2007

KDE-Windows Meeting: Notes

reducing distribution of the file by keeping a snapshot of files on our server(s)

this makes mirroring possible

having two or more main directories on the server: one for current stable release, one for 'unstable/testing' one

we need unstable releases to get people test software early and often and on Windows

'unstable' is the term for base system (kdewin32, kdelibs, kdebase); note that in turn, unstable _applications_ could be installed in a stable base system as it's the case on Linux

development installation requires tools having own installers

ideally this should not be the case for end-user installation, otherwise updating would be hard (user would be forced to uninstall prev. version of an external app and install a new one in the same place...)

We need someone using Vista on daily basis to test kdeinstaller. Until then Vista is not supported?

USB memory sticks/CDs: it would be possible to run kde apps/infrastructure installed on the stick/CD in two ways:

If the user's machine already contains KDE 4 runtime installed, it could be reused to run apps from the stick, and settings placed on the host conuter could be reused

If the user's computer contains no KDE-related stuff at all, default settings and .kde directory is used

In either case the default user expectation is that after plugging off the stick, no settings or files remain on the machine's filesystem <-really like that???

format of the kde mirrors:

TODO

Insert compiler name into package and manifest file name (msvc, gcc)

snapshot releases with debugging information

New developers may want to get the core libraries without a need for compilation from scratch, while still being able to step deeply into the its source code while debugging. This helps to enter into the project faster by fixing bugs, discovering structure of a given source code or extending features.

Could we have release versions with debug information? On msvc, this could help to achieve the goal mentioned in the above point while it is still possible to link release binaries with and without debug information.

reducing distribution of the file by keeping a snapshot of files on our

dbus for win32 is working mostly for recent kde applications, although there are some issues:

A service registered in dbus is not removed in case the related application crashes. This was detected with klauncher on msvc.