> 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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
