[Development] Qt 5 feature freeze

[Stephen Kelly]

On Thursday, January 05, 2012 10:04:38 lars.knoll at nokia.com wrote:
> We have around a month left until Feb 4th, the date I would like to start
> with a feature freeze for Qt 5, and it's high time we get some more
> structure behind things to see where we are and what's left to do.

I mostly agree with this.

> First of all, we need to define what the freeze means. I think it should
> include a couple of things:
> 
> * No new features go into the affected modules (see below however)

What a feature is might need some definition. How do we know a feature commit 
from a bugfix (or API fix or ...) commit? Are small features 'features'? Eg 
things similar to http://codereview.qt-project.org/#change,11783 ? Is a 
feature anything that needs to be documented (because it didn't exist before)?

> We should also define which modules are affected by the feature freeze. I
> think it's most important to freeze things at the bottom of the stack (ie.
> qtbase and declarative), but we should IMO look at all the modules that
> are currently considered part of Qt Essentials. In terms of repositories
> that means:
> 
> * qtbase
> * qtdeclarative
> * qtxmlpatterns
> * qtmultimedia
> * qt3d
> * qtlocation
> * qtsystems
> * qtsensors
> * qtwebkit (even though that's working slightly differentŠ)
> 
> Please tell me if you see larger issues with any of the above repositories.

Do the people working on them (the ones that are not qtbase) think early 
February is a reasonable target for them for feature freeze? Will they also 
add to the Qt 5.0 feature blocking bug to help visibility? 

> 
> Right now we need to get an overview over what's left to do before the
> freeze (and the possible exceptions to the freeze). The wiki page we have
> right now (https://wiki.qt-project.org/5.0_Feature_Targets) is a good
> start, but won't really allow us to follow progress towards the freeze in
> a decent way. To get this overview, let's have one blocker bug for the
> feature freeze. I already have
> https://bugreports.qt.nokia.com/browse/QTBUG-20885 as a meta task for the
> larger changes that need to happen for Qt 5.0, and would like to use this
> one to track what need to happen before the feature freeze.

The bug is also a good start, but it is a problem that people who are not 
Nokia employees do not have enough karma to do useful things with the bug 
tracker (assign and be assigned bugs, set priorities etc). Any timeline on 
that?

We also can't move existing bugs to be a subtask of that one. Can someone 
please move https://bugreports.qt.nokia.com/browse/QTBUG-22622 to be a subtask 
of QTBUG-20885?

> 
> This means that if you have something that you think needs to be done
> before the feature freeze (or is a feature that you need to get in as an
> exception later on), please create a JIRA task for it and make it a sub
> task of QTBUG-20885. It would be great if you could all spend some minutes
> this week to do this so that we have a decent overview early next week.
> 

Some of the items on the wiki are done, others are 5.x material and others 
should be migrated. I might be able to do that later, but other volunteers are 
welcome.

Will you keep that bug clean of tasks people put there that can wait until 
5.1? (Again, the karma issue)

> 
> To be able to reach the feature freeze, we'll all need to focus now on
> doing the changes that we can't postpone to Qt 5.1, and get them done
> within the next couple of weeks. It'll be quite a bit of work, but this
> work will define how Qt 5 will look like in the end.

Is there any update on your json object plans? Is that aimed at 5.0 or should 
it wait for 5.1?

> 
> 
> To summarize here's what we need to do now:
> 
> * Create JIRA tasks for everything you think needs to be done before the
> feature freeze and add them as subtasks to QTBUG-20885
> * tasks that are not done by Feb 4th need to be discussed on the mailing
> list and get approval from the maintainer as feature exceptions to be
> integrated later
> * all Source incompatible changes need to be reviewed by me in gerrit (as
> is already the case)
> * focus on getting the subtasks of 20885 done
> 
> Let's talk about how to get from the freeze towards an Alpha (and later on
> Beta/Final) release separately.

The only other thing I think makes sense is to have a freeze window at some 
point when features which did not make Feb 4 can be merged, instead of doing 
such a merge regularly. If there's still a steady flow of features in, then 
it's not really a freeze.

Thanks,

-- 
Stephen Kelly <stephen.kelly 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/20120106/8f80340a/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/20120106/8f80340a/attachment.sig>