KSecretService in KDE 4.6
winter at kde.org
Fri Oct 29 00:55:55 CEST 2010
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:
> 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
> 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
> 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.
More information about the release-team