KDE Quality (problems)

[Kevin Krammer]

Hi Clemens,

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 
maintainers easily.
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 
Amarok.
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).

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20110417/e33698c4/attachment.sig>
-------------- next part --------------
___________________________________________________
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.