[Development] Feature freeze date?

[Thiago Macieira]

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.

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

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

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.

> Is it a 'soft' freeze in that we can make a list of things that are going
> not going to make the freeze date, but which are known and will be
> committed when done?
> (Yes from me - I expect there to be people wanting to break freeze and
> already know that. Planned changes should be allowed, others not)

No, there is no "soft feature freeze". There's only a soft API freeze, meaning 
the features are *in*, but may change a bit to adapt to feedback and 
stabilisation. The feature freeze is hard: it's either done, ready for beta 
cycle and integrated, or it's not in this release.

During the beta cycle, we could decide to yank out a feature, but we should 
not add new ones.

It's possible to have some code in for a feature that is not public.

> Is there going to be a stable branch and summer (no freeze) in master?
> (I don't think it makes sense for this release - we'd need to define what
> has to happen between feature freeze and release and ensure focus on that)

Yes, we will need to start branching. How, it's a subject for another email 
thread.

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

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.

> Do you have any answer to that from your POV? Still planning on getting QUrl
> and Q_GLOBAL_STATIC improvements in?

Yes: both features are complete in my tree (Q_GLOBAL_STATIC has been done 
since August and QUrl since October). I'm waiting for a permission to publish 
them in Gitorious in the coming days, but I cannot submit them to Gerrit yet.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111214/9c1ffd0a/attachment.sig>