On 12/15/11 7:25 PM, "ext Peter Hartmann" <peter.hartm...@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@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >_______________________________________________ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development