[Kde-games-devel] Regression testing

[Mauricio Piacentini]

> Yes, Plasma will show severe breakage with Qt 4.4. Lowering the requirement is
> not an option if we want a functional desktop shell.
>
> In this case, I'd actually opt for removing kolf from the release. It's not
> ideal and painful, but as it seems, we have to decide between a broken Kolf
> and a broken Plasma, Kolf, with all due respect is less critical for most of
> our users.

You are correct, of course. Given this choice there is really no other option.
I tried to fix Kolf again today, but failed to understand why it has
broken. I know the kde-games community took a shared responsibility
for maintaining orphaned applications, and we are doing our best at
it. But it is difficult when a major piece of technology that is not
under our control keeps changing in subtle ways, and breaking our apps
at every 2 or 3 months.

Notice that I am not saying that the app is perfect to start with, but
if you look at the last releases each broke a different KDE game in a
subtle way.

And every time we had a problem in the last releases it was connected
to a change in QGraphicsView, which has been sort of a moving target.
KMahjongg and KGoldrunner, who used KGameCanvas, did not suffer from
this. Several games that used QGV did suffer at different times.
Kapman broke completely, then KMines. KPat had (might still have, I am
not following it) redraw issues, and Kolf is completely broken with no
change in our code. KBlocks exhibits weird drawing since version 1.0,
as I chose not to work around the bug that caused it with SVG
elements. These redraw and display issues accont for probably 50% of
our bug reports recently, if not more. All of this was understandable
at 4.0, and Ian and me both spend a lot of time chasing bugs there,
but it is no longer fun after almost three years. Gladly, Plasma folks
are doing a very good job at keeping at least the desktop shell under
relative stability and taming QGV issues. Maybe the higher visibility
of their work ends up producing better/faster results when attempting
to solve these issues compared to our efforts, or maybe they are just
better at colaborating with the Qt people that maintain those pieces
of code :)

So I think it is time we lay out a plan to deal with these situations
in the future. I would say we need to implement:

a) Better (or any :)) regression testing at every Qt release.
b) A policy where applications that have stayed in the module with no
active maintainer for a given period of time need to be Q&A'd by the
module maintainer, if no one else steps up. If problems can not be
solved, they should probably be removed before the RC.

Regards,
Mauricio Piacentini