[Development] Qt 5 feature freeze

[lars.knoll at nokia.com]

On 1/6/12 8:32 AM, "ext Stephen Kelly" <stephen.kelly at kdab.com> wrote:

>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)?

Yes, we don't really have a definition currently. I personally don't mind
if the definition is a bit fluffy and allows for judgement calls. But to
give some general rules, I'd say that a feature is anything that

* adds functionality to the libraries
* larger refactoring of code
* stuff that has a higher risk of breaking other people's code

> 
>> 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?

>From talking to them I believe it's ok for most of them. But that's why
I'm asking here, so that any maintainer seeing large problems can speak up.

> 
> 
>> 
>> 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?

Yes, this sucks. I thought this had been fixed by now. I'll follow up on
Monday to see when the move of bugreports to qt-project.org will happen
and how we can fix permissions.

> 
>> 
>> 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)

I'll keep track of things, yes.

> 
>> 
>> 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?

It's not on the blocker list, since it's technically not something that
couldn't be done for 5.1. But I am still planning to get it in. I'm mostly
done by now, there's a little bit of work left to make it safe on
big-endian machines (I'll need to find one to actually run the tests
though...), do an API review and write docs. I should be done with that and
have it ready by end of next week.

> 
>> 
>> 
>> 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.

Yes, there will be one day where we merge them into the master branches of
the repositories. But I'd like to create a CI controlled
feature_exceptions branch on gerrit (at least for qtbase, let's see if any
other repos need it). I'll merge from master into that branch in regular
intervals, and we can push all features into that branch as they are done.

This gives us both an incremental way to test the features, and one well
defined time where we merge them all into master.

Cheers,
Lars