This starts to become a dangerous path (Was: New Feature for kdelibs)

Alexander Neundorf neundorf at
Tue Nov 15 21:16:11 GMT 2011

On Tuesday 15 November 2011, Thomas L├╝bking wrote:
> Am Tue, 15 Nov 2011 15:20:44 -0500
> schrieb Scott Kitterman <kde at>:
> > It's already happening, so the real question is how to minimize the
> > impact.
> This is why i've posted this mail in the first place.
> "Minimizing the impact" means to align up- and downstream, ie. find
> a way to provide features *now* w/o really opening kdelibs to new
> features but at best accelerate frameworks development.
> (as you probably read in the rest and unfortunately not commented part
> of my original post)

Hmm. AFAIK we have currently two cases. One is SecretService and the other one 
is something with cookies or so.

How about "it is ok to add it to kdelibs if it is also added to frameworks" or 
something like this ?
This would also be very different from "kdelibs is open".

I fully understand that it makes a lof ot sense to feature freeze kdelibs for 
the frameworks effort in general.

But nevertheless I don't see what the bad impact of allowing secretservice to 
go into kdelibs now would have, assuming Valentin ports it also to frameworks. 
Same for the browsing stuff.
The code is there, works, has been reviewed, announced very early, etc.


More information about the kde-core-devel mailing list