KDE's rough edges... what are your experiences?

[Michael]

Am Thu, 31 Oct 2013 14:58:43 +0100
schrieb Kevin Krammer <krammer at kde.org>:

> On Thursday, 2013-10-31, 11:45:04, Michael wrote:
> > Am Tue, 29 Oct 2013 14:35:29 +0000 (UTC)
> > schrieb Duncan <1i5t5.duncan at cox.net>:
> 
> > > Up the stack at the application level, kde5 is breaking up and
> > > shipping most individual apps with their own version tagging and
> > > release timing, so apps that are evolving fast can ship updates
> > > every month or even every week if they wish, while already mature
> > > apps in primarily maintenance mode might ship an update a year,
> > > mostly just to keep them building on current libraries with
> > > current tools, with the occasional security update as well when
> > > necessary.
> > 
> > With QT4 / KDE4, could applications not just build against maybe
> > older qt- / kdelibs which would then not prevent fast-paced
> > application-development?
> 
> There are already quite some applications that have their own pace,
> e.g. Amarok and Digikam, so this is mostly an option that might be
> explored by more applicatons in the future.

So it *is* possible with qt4 / kde4 already and not a feature (planned
or already done) in qt5 / kde5. To convince other application
developers to do the same, no idea how qt5 might help help there. As I
guess the most obvious reason for slower paced development is just lack
of manpower. Any pointers there that qt5 does actually help?


> The relation to the KDE Frameworks 5 initiative is that are
> consideration to potentially release frameworks separately or in
> smaller groups on individual schedules. When the release of
> dependencies is no longer synchronized, it becomes more unlikely that
> things built upon them are released in a synchronized fashion.
> 
> But, as I said in another posting, this is not definit yet.

Uh... even after reading that paragraph several times, I seem to have
some issues understanding it. O_o So... come again? Or point me to the
other mail, maybe that will clear things up.


> > > That means currently qt-but-non-kde apps and desktop options may
> > > become more popular as well.  There's smplayer, and the razor-qt
> > > desktop.
> > 
> > Right, there *is*! No idea why the new "de-coupling style" benefits
> > such projects. BUT ignore the question you might see here, as it
> > will go in a direction which is out of the scope of this thread.
> > Really, don't answer the question, ignore it.
> 
> 
> Should probably not ask it then ;-)

Yeah! :-) But it is kind of hard to make the balancing act between
showing Duncan what parts *could* (or should) be skipped and carrying
on the overall conversation. The idea was to show him a possible
conclusion a person might have and as the reaction to that conclusion
would miss the scope of the conversation, try to convince him to not
answer it. But agreed, under normal circumstances I would not have
written a thing that could be understood as a question when I don't
want that question to be followed in the first place. But in this case
the idea may have failed or was a bad idea to begin with...
whatever. :-)

> It is somewhat relevant though. Making KDE technology more available
> to projects currently not using it has the potential of increasing
> the number of people working on them.
> Another thing that influences the topic of QA is that part of the
> effort is to increase test coverage, or, making the tests more
> explicit (things that got lots of implicit testing through being used
> by other parts now gain their own tests).

As I don't want to go there any further anyway: We'll see. ;-)

regards
Michael
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.