[Development] Feature freeze date?

[lars.knoll at nokia.com]

On 12/15/11 7:25 PM, "ext Peter Hartmann" <peter.hartmann at nokia.com> wrote:

>On 12/14/2011 06:42 PM, ext 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
>
>my addition for network (feel free to point out more):
>
>
>== Network ==
>
>* SSL errors (+ OCSP etc.): make it possible to display SSL errors
>without stalling QNetworkAccessManager
>(http://bugreports.qt.nokia.com/browse/QTBUG-19032)
>
>* Authentication: make it possible to display authentication dialog
>without stalling QNetworkAccessManager
>(https://bugreports.qt.nokia.com/browse/QTBUG-16251); this is obviously
>closely tied to above task
>
>* remove QHttp (https://bugreports.qt.nokia.com/browse/QTBUG-22750)

* Make QFtp private

Cheers,
Lars

>
>* rewrite cookie jar (https://bugreports.qt.nokia.com/browse/QTBUG-23145)
>
>
>Peter
>
>
>>>
>>> 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.
>>
>> If we reach the feature freeze date and a requirement isn't complete
>>yet,
>> we'll need to make a call whether to delay the freeze or not. This is
>> something we'll do only for 5.0, as for any future releases, anything
>>can be
>> postponed.  That also means we don't have "feature requirements", but
>>only a
>> wish-list. [That's between us developers; in public communication we
>>may call
>> them differently]
>>
>> For those things that can be postponed, we should have a separate
>>roadmap
>> page. We can also start collecting ideas for future releases.
>>
>>>>> 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.
>>
>> Depending on whether you referred to source or binary incompatible
>>changes;
>> and for the source ones, it's understood it applies to new features
>>only.
>>
>>>> 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.
>>
>> 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, 61Ž2 years since ItemViews and the rest
>>of the
>> Qt 4 API.
>>
>>
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development