[Development] Feature freeze date?

[Peter Hartmann]

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)

* 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, 6½ 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