KSecretService in KDE 4.6

[Allen Winter]

I believe exception requests must go through the release team,  so I'm redirecting.

On Thursday 28 October 2010 3:25:56 am Michael Leupold wrote:
> 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.
> 

I think we should grant this request.
I have no objections.

10 days review time seems good enough to me.

Committing to trunk 3 days after the hard freeze isn't a big deal either.
If desired, extending the hard freeze 3 days wouldn't be so bad.

We aren't that intransigent.

-Allen