[Development] Feature freeze date?

Wed Dec 14 18:12:21 CET 2011

On Wednesday, December 14, 2011 17:07:21 Thiago Macieira wrote:
> On Wednesday, 14 de December de 2011 15.43.56, Stephen Kelly wrote:
> > > Also: what are the things we must still do before feature freeze?
> > 
> > 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.
> 
> Understood, but we must also not linger. I do expect the stabilisation phase
> to take several months. I'm talking about feature freeze, not release date.
> Also, I am asking what's left to be done before the feature freeze.

Ok, well let's start the list:

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

One thing we could do is:

1. Let people populate the list
2. Review the list for plausibility in a reasonable timeframe 
	and personal availability.
3. Estimate the time for the responsible people to get the work done.
4. Schedule feature freeze based on that.
5. Features that unfortunately don't get finished by then don't make 
	it into 5.0, and possibly .x.

That's just an idea of how to make progress though. Making a scheduling 
decision without any idea of what needs to be done in that timeframe doesn't 
really make sense.

> 
> I think we need to agree on what the milestones mean before we can make a
> decision and I think we didn't have the same meaning when I posted, which
> might be why you disagree with me.
> 
> > 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.
> Rewrites, I'd like to see done by the feature freeze. But refactorings of
> the internal code can be done in 5.1 too -- if the API isn't affected. 

Yes, that is hard to know and can't be evaluated until there are no more 
rewrites going on or planned. The changes I have planned for 
QVariant/QMetaType do have implications which mean they must be in before 
feature freeze. 

If one person is doing a rewrite, that makes it harder for others to implement 
features in terms of the rewritten API before it is done, add their own API 
etc. 

If this rewrite stuff is limited to QVariant/QMetaType and is not 
underway/planned for other stuff (I'd be surprised - The accessibility stuff 
is also being re-written), then maybe it's not a really big deal. We'd just 
need to find out when the most large changes, and changes with the most 
repurcussions to other features will be done.

> What
> needs to be done *now* are things that affect Qt's BC guarantee or fix
> broken API. Or major restructurings, like the new GUI architecture.

Yes.

> 
> > 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?)
> 
> No, it does not, not completely.
> 
> For a regular 5.x release, it means "all features are in and we're starting
> the beta cycle". For 5.0 specifically, I'd relax it a bit, knowing the beta
> release will take more work, hence more time. Remember my definition of a
> Maintainer's job: ensures that his/her codebase is always ready for beta.
> 
> I'd say the API freezes as:
>  - feature freeze & alpha: all features are in and work, users of the API
> can use it and will give feedback; the purpose of the Alpha release is to
> validate the API and get feedback on whether it really does work and solve
> the problems it was intended to.
> 
>  - beta: API is soft-frozen and will almost not change anymore; users of the
> API can start depending on it; any changes from this point on must be
> properly communicated; the purpose of the Beta release is to start using
> the API and to validate the implementation (not the functionality), by
> fixing bugs and finding issues.
> 
>  - RC: API is deep frozen and will not change unless a catastrophic flaw is
> found; you'll have to convince the Release Team to postpone the release; BC
> should not change anymore [soft-frozen].
> 
>  - Release: API is completely frozen; SC and BC guarantees kick in,
> including forward compatibility for the patch releases.

This all looks reasonable.

> 
> By "API" here I mean the source-compatibility as well as behaviour. By BC,
> it means anything affecting compiled code, like symbol mangling but also
> data layout format. Where applicable, ABI-changing options to the compiler
> too.
> > New virtual methods freeze?
> > (Yes from me)
> 
> No, see above. BC kicks in only at release, but should be soft-frozen at RC
> time.
> 
> > Backward incompatible change freeze?
> > (Yes)
> 
> See above on both SIC and BIC changes.

Right. This would be soft-frozen probably at RC or beta time.

<snip>

> > For a list of things KDE needs to get into 5.0 see
> > 
> > http://community.kde.org/Frameworks/Epics/Qt_5.0_Merging
> 
> I think the page above is mis-named. 

I agree. I didn't name it :). The word merge also shouldn't appear on the page 
at all.

> It's technically what we need for a KDE
> Frameworks 5.0 release, but it does make them Qt 5.0 requirements.
> 
> The QDateTime, QCalendarSystem and QLocale changes are still outstanding.
> Those are definitely Qt 5.0 requirements, especially considering QLocale
> might include non-SC or behaviour-changing changes.
> 
> What is the "Contact John Layt to get an update" entry, for which the
> contact is Mario Fux?

Presumably John hasn't been on IRC or sent a status update in a while and 
Mario is tasked with finding out the status.

> 
> Of the "TODO" items:
>  - QLockFile and QSaveFile - not a 5.0 requirement, can be accepted in 5.x
>  - QCommandLineArguments - same
>  - KUrl/QUrl merges + QUrl rewrite - 5.0 requirement
>  - Q_GLOBAL_STATIC - 5.0 requirement
>  - KDebug features into QDebug - probably contains 5.0 requirements
>  - KProcess/KShell features - same, probably contains changes for QProcess
>  - QMenu - I can't judge
>  - QSqueezedTextLabel - not a 5.0 requirement
>  - QCompleter - I can't judge
>  - QIcon - I can't judge
>  - QLocalSocket abstract sockets - not 5.0 requirement
> 	unless we want to change the default
>  - QSystemTray notifier protocol - not 5.0 requirement
> 	however, QSystemTray working with Lighthouse is a 5.0 requirement
>  - QCryptographicHash - not a 5.0 requirement
>  - QFileSystemWatcher - not a 5.0 requirement and a replacement is nice
> anyway - i18n - probably a 5.0 requirement
> 
> Of the "I can't judge" QtWidgets features above, considering that module is
> in Done state and we have a source-compatible requirement for 5.0 for
> existing features, I would wager that they are not Qt 5.0 requirements.

Yes, but there are also lessons which we need to ensure are not forgotten so 
that we have useful API for QML. An example is the QCompletion stuff. Doing 
that 'properly' and in a future-proof, QML compatible way probably actually 
depends on itemmodels getting new features, such as a virtual search() method 
to supercede the match() method. That's just an example. There may be others.

<snip>

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/369b836f/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/369b836f/attachment.sig>