[Development] Feature freeze date?

[Stephen Kelly]

On Wednesday, December 14, 2011 18:42:49 Thiago Macieira wrote:
> On Wednesday, 14 de December de 2011 18.12.21, Stephen Kelly wrote:
> > 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.
> 
> That's why I started the thread. We need to know what we need to do so we
> can make a scheduling decision. Or, alternatively, we need to decide what
> we can do given the schedule.
> 
> I also oppose to your item #5 above. I don't want to see anything on a page
> called "5.0 requirements" that can be postponed. I want *only* the stuff
> that *must* go into 5.0, i.e., what cannot go into 5.1 or a later release
> until 6.0.

My item number 5 is for stuff like 'We wanted the new {QUrl,QDateTime,QLocale} 
but the work is not in gerrit for reason x, so while it would have been nice, 
we'll have to manage without it, as we have managed with it in Qt4 up to now.'

It's for 'If it happens at all it will have to happen for 5.0. It can't happen 
after that, and if if doesn't happen before that, then it doesn't happen' 
items.

So yes, as you write below (snipped), it's more of a wish-list.

<snip>

> > 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.
> 
> I agree. However, we'll never finish finding new requirements or need to
> improve the API, so we need to make a cut somewhere based on our best
> understanding. I might be an optimist here, but I'd have expected all these
> studies where we need new API to have completed by now. We're 5 months into
> the 5.0 cycle, 1 year into the QtDeclarative API, 6½ years since ItemViews
> and the rest of the Qt 4 API.

True, but for the most part, realistic and achievable plans for Qt5 API are a 
recent thing, any maybe are still only in the heads of people who have been 
working on the stuff in TT/Nokia.

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/20111215/a22caedd/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/20111215/a22caedd/attachment.sig>