<br>For KDEgames, we are now in time, and i like to focus now on quality now, for example harmonize usability between games...<br><br>But i'm not against a delay, because as aaron said, some KDE part still need work and time to mature or be ready (i'm thinking to plasma that seems starting to work, but need to mature more before to be freezed (aaron, fix me if i'm wrong), kcontrol that doesn't seems to do anything, kicker? ...). Because if we are keep actual date, with our current status, we risk to disappoint our users and be flamed. Even worse, put a regression/useless/buggy image on KDE
4.x, because it is hard to communicate that 4.0 and 4.x is not the same thing.<br><br>Other point, it was said that the agressive 4.0 r<span class="q">elease schedule was also to allow devs to developp and port applications for
4.x. What is the purpose without kdevelop and win/osx port?<br><br>I propose a </span>25 July feature freeze for the sub-module which *really* need it, and keep the 1june for others, like kdegames, to focus on quality (usability, artwork...). At least, some
KDE4.0 parts could give a polished image to 4.0, and some frozen dev could even help the latecomer sub-modules to be good enought. <br><br><br><br> <br>