[Development] Feature freeze date?

[Stephen Kelly]

On Thursday, December 15, 2011 06:40:35 lars.knoll at nokia.com wrote:
> Hi everybody,
> 
> sorry for not answering earlier. I actually wanted to bring the topic up
> myself, but just didn't get it out so far. I've simply been traveling a
> bit too much (I'm currently in Tokyo for the local Qt Developer event,
> after we had a great one in Beijing two days ago with round 1100
> participants).
> 
> So let me try to summarize my thoughts on the the feature freeze date,
> what it means and how to move from there.
> 
> The feature requirements wiki page is a great initiative. But as Thiago
> said: let's really limit it to the things that can't be done in 5.1. If a
> it's something that can be done in a binary compatible way, it should not
> be on the list.

As far as I know, nothing on the list so far could be in 5.1 (except maybe 
Q_GLOBAL_STATIC - that was undocumented in Qt4 so it's 'new' API anyway).

https://wiki.qt-project.org/5.0_Feature_Targets

Even saying that though, I am certain that the list is incomplete.

One thing that comes to mind is relying on ICU for unicode and locale data, 
which was brought up on the mailing list but is not on the wiki. json support 
is another, but as new API that could go into 5.1. They're just things that 
you recently brought up, but I'm certain other people have features they want 
that can not go into 5.1 (is there on going event dispartcher work? Does 
declarative want to have a synchronous schedule with Qt base for the 5.0 
release?).

And if they don't get in before feature freeze (eg the new QUrl, json support, 
ref counted quit), then we simply do without them for Qt5 just like we did 
without them in Qt4.

> 
> Once we have the list, let's go through it and do some estimations of what
> it requires. But let's avoid falling into the trap of requiring a perfect
> world/solution. No matter how much time we give ourselves, we won't be
> able to do everything we maybe would like to do, and we'll have to cut of
> at some point.

Yes. We would need to actually have a target list before we can know what is 
not going to make the target though and what is unrealistic.

> It doesn't make sense to freeze BC before the final 5.0.0 release, so
> let's not do that. As long as your change is source compatible, we can do
> binary incompatible changes almost until the end.

I think it depends on whether a set of new virtual methods create a 
significany part of the API, but yes, that's more covered by API freeze than 
BC freeze anyway, so not freezing BC before 5.0.0 sounds good.

> 
> 
> I believe we need to stick with the feature freeze timeline by end of
> January. I know that this hasn't been a huge amount of time for externals
> to get their changes in, but we have finished most of the fundamental
> changes that were needed for 5.0. Jan 31st is a Tuesday, so my proposal
> would be Feb 3rd.

I believe we need to enumerate the targets before we schedule a freeze. 
Scheduling it before knowing what is targetted and whether it's a plausible 
target is only going to lead to people trying to rush the feature in or things 
like 'Just +2 it so that it gets in before freeze. We can fix it later', which 
would run counter to the reason for having a freeze anyway. 

We need to have feature targets before scheduling feature freeze.

I actually think I can meet my targets personally, but I don't want to work to 
the bone to get it done and then have others break freeze for things that they 
bring up in mid February 'because we need it'.

> I also still believe strongly that we need to aim for a Qt 5.0 release by
> next Summer. It is important that we get 5.0 out as fast as we can to
> establish a new baseline for Qt development. If we want to be able to keep
> that date we need to start freezing things soon.

Sure. But we can't just say 'soon' and pick an arbitrary date without knowing 
what we're targetting.

Should we also send a message that everyone should prefer to work on things 
that can only go into 5.0 and can not go into 5.1 to prioritize that? (such as 
the json APIs).

> In case you feel there is a change that *has* to go into 5.0, but that you
> think you'll not be able to finish until the feature freeze I'd like
> people to speak up on this list as soon as possible and we'll then figure
> out how to handle them.

Not only if you think you won't make the freeze deadline, but if you still 
have features you want to integrate, please put them on the wiki.


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/20111220/337d85d9/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/20111220/337d85d9/attachment.sig>