KDE Quality (problems)
kevin.krammer at gmx.at
Sun Apr 17 16:19:23 BST 2011
On Thursday, 2011-04-14, Clemens Eisserer wrote:
> The problems I see are:
> 1. Too few developers, too much code
> 2. Too short release cycles & Quality testing
> 3. Features count most mentality.
> 4. Performance
> I normally wouldn't bother the list with my ideas, however I have been
> encouraged to do so.
Appreciated. Most items seem to be to the point though I think some might be
based on a bit of misunderstanding.
> Ad 1.)
> I participated during the kde 4.2/4.3/4.4 beta phase - and came to the
> conclusion it was mostly
> worthless effort on my side. There are simply not enough contributors
> arround to fix all the open issues.
> I have already a few projects I contribute to, fixing the bugs myself
> is simply no option :/
This is unfortunately true.
One problem is of course the increasing code base over the years, adopting the
platform and applications to newer requirements.
IMHO this part of change in ratio of developers to lines of code would in
itself not be a problem per se as only major transition points like Qt3 -> Qt4
make going through a lot of code necessary.
The main problem of is "losing" long term contributors, because it is not the
amount of developer available which counts but the amount of knowledge each
developer has on the part of code they are working on.
Some spots are of interest to many people and as such find even new
Others not as lucky, e.g. printing. Initially there was hope (correctly IMHO)
that Qt4's improvements over Qt3 in this area (e.g. built-in PDF generator)
would allow KDE to rely on its dependencies a bit more.
In this case we were unfortunately let down, so it took a while until some
brave soul put this topic onto their (already quite full) plate. Thanks John!
> Furthermore KDE accumulated tons
> of code over time (I still don't see the reason it carries its own
> Office-Suite, HTML-Rendering engine, instant messanger, Media Player,
> whatever), but only few guys are actually working on the code.
Lets do the easy one first: HTML-Render engine
API and ABI compatibility and no desire to go for KDE5 right now.
Office-Suite is most likely referring to KOffice, Media Player probably to
Neither of which is part of a KDE software compilation release, thus not bound
to any release schedule.
Instant messenger and Media Player (in case this refers to something else):
true, mostly a result of sharing libraries between applications which are not
deemed to be API/ABI stable enough (yet) to be considered platform.
It might be possible (and maybe even desirable) to allow each module to have
its own release cycle.
> Ad 2.)
> Another problem is the release cycle. The cycle is so short, that even
> many bugs reported during
> alpha stage aren't fixed. At release-time, devs are already working on
> new features, often not backporting their fixes.
> So you end up again with release+1, this time with other bugs.
> Its not uncommon for me to see integral parts broken after updating to
> a new major (like the panel in my multimonitor setting when updating
> to 4.6).
I don't think it is actually the length of the release cycle itself, my guess
is that it is more of a question of the ratio between unfrozen and frozen
periods within the cycle.
This is one of the things that hopefully will get better due to the recent
switch to git as our version control system.
While SVN did support branching, tracking changes across several branches
became quite difficult, resulting in most development to happen in trunk.
git is a lot better in this regard, allowing development parallel to several
releases, i.e. basically making it possible to only fold back fully
implemented new features.
So each release cycle's unfrozen period could be shortend considerably, e.g.
like the Linux kernel's merge windows.
> Ad 3.)
> Features count most. Plasma may still be not completly stable,
> and the TaskManager may do weird things (both from a user perspective
> absolute core-components),
> however wee see social network integration and whatever.
I don't think this is true across the spectrum of KDE products, though it is
definitely more prevalent in the workspace area.
My take is that this area is the one with most changes in requirements and
also competition so developers there might be inclined to work on new
challenges when the current solution works reliably for them.
E.g. attemping a different implementation based on QML and its scenegraph
inspite of these technologies not being very stable yet.
> Ad 4.)
> I remember KDE4 was praised for using less memory and beeing faster than
> 3.5. I knew that would't become reality, 4.6 uses about twice the amount
> of memory 3.5.11 used and starts up way slower.
> Paint performance is mostly bad, but instead of improving the painting
> all simply paint to X11/Xorg and praise the QT-Raster backend which is
> here to solve all problems.
> Guys, XRender has arrived and is implemented by drivers well. If QT /
> your code can't use it - don't blame X11.
Well, according to the developers who came up with XRender, it is basically
just a stop-gap measure to get some features potentially hardware accelerated
while fitting close enough to the usual X11 API.
(And it depends on the Xserver implementation being used, got bitten by that
at work when a customer was using one of these proprietary Xservers, yuck).
For Qt, the raster graphicsystem is actually quite good, even default on
Windows, but on X11 the default is still X11 with Xrender.
Using raster might actually make things faster (it did on Windows, so why not
also on X11).
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
-------------- next part --------------
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde