[proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
kevin.kofler at chello.at
Sun Nov 13 23:43:29 GMT 2011
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:
What I don't see is why the long-term development needs to happen at the
expense of short-term development.
More information about the kde-core-devel