On Tuesday, December 13, 2011 21:18:34 Thiago Macieira wrote: > So... > > When are we supposed to freeze? During Dev Days two weeks ago, we started > discussing about it being in January. > > Can we set a more precise date? Let's say, a week [*]? > > Also: what are the things we must still do before feature freeze? > > [*] note: week numbers in 2012 will differ from the ISO reckoning and the US > one again, by 1.
I think January is quite early, considering that means just between 2 and 6 weeks from now. There has been very little time for people outside of Nokia to get features in. Opengov was only launched at the end of October. Before that there was the gitorious system, sure, but that wasn't enough for several reasons. Considering that it can take a long time and a lot of energy to get a feature into Qt, between getting reviewers to agree (there are many chefs in the Qt kitchen), waiting on people to review, waiting for other people to get their changes in etc (currently I'm waiting on some QVariant changes to get in so that I can rebase http://codereview.qt-project.org/#change,10409 onto it (and rewrite parts of my patch)). It's not even very parallelizable, so that is not a lot of time. It's hard to even know what we still need to get in in a binary incompatible way for 5.0 (that which can't go in in 5.x). The QVariant/QMetaType stuff is still undergoing some major rewrites and other parts of Qt are too. We also need to understand what feature freeze means. Does it mean API freeze? (My opinion is yes, it would need people to enforce it?) New virtual methods freeze? (Yes from me) Backward incompatible change freeze? (Yes) Is it a 'soft' freeze in that we can make a list of things that are going not going to make the freeze date, but which are known and will be committed when done? (Yes from me - I expect there to be people wanting to break freeze and already know that. Planned changes should be allowed, others not) Is there going to be a stable branch and summer (no freeze) in master? (I don't think it makes sense for this release - we'd need to define what has to happen between feature freeze and release and ensure focus on that) For a list of things KDE needs to get into 5.0 see http://community.kde.org/Frameworks/Epics/Qt_5.0_Merging It's not entirely clear which of those can not go in in 5.x. Datetime and calendar stuff in particular is something I'd like to see improved in 5.0. I don't think very major changes to it would be as acceptible in 5.x. > Also: what are the things we must still do before feature freeze? Do you have any answer to that from your POV? Still planning on getting QUrl and Q_GLOBAL_STATIC improvements in? Thanks, -- Stephen Kelly <step...@kdab.com> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development