[proposal] Move all of the ksecretsservice components into kdeutils/ksecrets

[Kevin Kofler]

Sebastian Kügler wrote:

> On Saturday, November 12, 2011 08:12:27 Kevin Kofler wrote:
>> All this stuff is going to make things much more work for us packagers
>> (just  like the separate kactivities), for no good reason other than some
>> arbitrary "we froze kdelibs" decision!
> 
> Calling it an arbitrary decision shows either of two things: you ignore
> the rationale behind it, or you don't understand it.

It's true that I don't understand the rationale behind the freeze, and never 
will. It just doesn't make sense.

Developing for the future needs to be done in parallel to developing for the 
present, not at its expense.

Note that I do understand the rationale about Frameworks 5 to some extent, 
though I'll admit that I'm not enthousiastic about yet another major binary-
incompatible version and that I'm worried about the undesired side effects 
of reducing dependencies (from a quick look at the current frameworks 
branch: lost features (e.g. tilde expansion in KUrl), lost consistency (e.g. 
use of QFileDialog rather than KFileDialog, and last I checked QFileDialog 
only supported native dialogs with the static methods, so when you construct 
a QFileDialog object, you'll get the ugly Qt-only one), possible code 
duplication to avoid a dependency (not seen in frameworks yet, but I've seen 
this elsewhere and am worried that it might happen in frameworks too, 
especially when you'll try to actually fix that code you just "#if 0"ed 
without readding the dependency)). It's the freeze of kdelibs 4.x I have a 
problem with, not Frameworks 5 per se.

> Frameworks 5 was a very conscious decision taken by the people, who by all
> reasonable means are in the position to do so, and so was freezing
> kdelibs. I understand you're not happy with this decision, and I'm sure by
> now everybody else knows that, too -- no need to repeat it over and over
> again without any added value. People are actually getting tired of it.

And I'm getting tired of seeing issue after issue pop up here, all caused by 
that freeze, and the obvious solution to the issues getting summarily 
rejected. Am I really alone in that? :-(

> Stating the bleeding obvious, if you want to get kdelibs (or its
> successor) open to feature additions, help getting F5 ready, don't make it
> take longer.

If I didn't care about the long term, why would I have removed all the 
remaining Qt3Support and kde3support usage from Kompare recently?

See for yourself:
http://websvn.kde.org/trunk/KDE/kdesdk/kompare/?view=log

What I don't see is why the long-term development needs to happen at the 
expense of short-term development.

        Kevin Kofler