10 Days Until Next Milestone

[Mauricio Piacentini]

>> I propose a 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.
> 
> Since kdegames is in good shape, I guess they have time left for new features. So freezing the modules that are in good shape seems silly to me now that I think of it.

On the other hand, without a module freeze we can not really shift our 
focus to stabilizing and really finishing all the games. There is always 
the temptation to rescue that game that did not make the cut for 4.0, 
and maybe adding that big feature that we know will not be fully matured 
in the next 150 days or so.

I support Johann's idea, of only extending the feature freeze for the 
modules and apps that really need it. In our case, I guess the proposal 
made by Allen seems nice:

1. 1 June is changed from new feature freeze to new application freeze
   2. We move the feature freeze to the start of the second beta (approx 
25 July).
        As this is also when the string freeze occurs.

So each individual game could perhaps use this time to implement a 
missing feature, but we would not add new games to the module after June 
1st.

Regards,
Mauricio Piacentini