KSecretService in KDE 4.6

[Michael Leupold]

Hi,

as announced at Akademy we would really like to get a first 
implementation of ksecretservice into KDE 4.6 in order to further the 
project and adoption of the new D-Bus API. However due to various 
work-work and personal reasons I haven't been as productive as I would 
have liked to be during the last month and - as a result - there are 
some things left to do before ksecretservice can be merged into trunk.

When looking at the release schedule I was quite baffled. Somehow a 
4-week period between soft and hard freeze was stuck to my mind. 
Obviously the 2 weeks we are left with doesn't leave us with enough time 
to finish everything needed to release AND have a proper review period.

Therefor I'd like to ask for an exception in order to still get 
ksecretservice into KDE 4.6. We're very dedicated to the project and I 
managed to get some time off work-work in order to improve the chances 
of finishing in time.

The parts to be merged will be:
- A new implementation for KWallet::Wallet using the secrets storage 
D-Bus API (ksecretserviced, gnome-keyring). It is meant to enable a 
smooth transition to the new client API to be released with KDE 4.7. The 
new implementation will not sport any new public API.
- A new daemon implementation called ksecretserviced which fully 
replaces kwalletd and uses the new D-Bus API. It will end up in 
kdebase/runtime.

This is the timeline which seems reasonable in order to finish:
04.11. Move both parts to kdereview
14.11. Merge with trunk

So this would involve both a shortened review period of 1.5 weeks as 
well as merging after hard freeze. Tests are already in place and 
extended in parallel to the actual code. We're well aware that angering 
our users by releasing something that puts their secrets in danger is 
not an option and are committed to either releasing quality or not 
delivering.

I'd be grateful if we could make this work somehow. If you have any 
questions I'd be happy to answer them.

Regards,
Michael