[Development] Qt 5 feature freeze

lars.knoll at nokia.com lars.knoll at nokia.com
Thu Jan 5 11:04:38 CET 2012


Hi everybody,

first of all let me wish you all a happy new year. I hope you all managed
to have a nice break over christmas. I spent the last two weeks with my
family relaxing and skiing. I was mostly successful in not touching a
computer during these days :)

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.

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)
* We start focusing on testing, bug fixing and improving our test coverage
* We start a process to package up what we have as a Alpha/Technology
preview of Qt 5
* We are a lot stricter about keeping SC
* We do *not* need to keep binary compatibility until the final release

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.

Other modules/repositories can follow the feature freeze if they want to,
but I'd very much like to leave it up to the individual maintainers to
decide.


I do however see that we will not be able to finish all features
everything until Feb 4th. So there will be a list of exceptions that we
can then try to integrate in a block directly after we released the Alpha.
We need to however keep tight control over these exceptions, and I'd like
to propose that each one of them has to be discussed on the mailing list,
and requires approval of the responsible maintainer.

Decision criteria for allowing exceptions should be:
* Does it affect other parts of Qt?
* How good is it covered by automated tests?
* How crucial is it to get this into Qt 5.0?

For managing these exceptions I'm thinking of creating a
feature_exceptions branch in gerrit, that will be CI controlled and will
regularly merge from master. All features that are done after feb 4th will
get pushed into this branch. After the Alpha, I'll then merge this branch
back into master.

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.

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.


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.


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.

Cheers,
Lars





More information about the Development mailing list