[Development] Feature freeze date?

[Stephen Kelly]

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 <stephen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111214/0e3229b5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111214/0e3229b5/attachment.sig>