KSecretService in KDE 4.6

[Will Stephenson]

On Friday 29 October 2010 00:55:55 Allen Winter wrote:
> 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.

I just checked with Michael, this didn't get done in time so KSS is delayed 
until 4.7.

Will