On 9/6/11 1:14 AM, "ext Thiago Macieira" <[email protected]> wrote:
>On Monday, 5 de September de 2011 21:32:15 [email protected] wrote: >> I don't really think the gap in features matters that much right now. We >> know that this change has to happen, and the earlier we do this the >> better. The reason is that it sets the direction for Qt 5 and gets >> everybody to work on the same stack. > >Those are good reasons. > >> So I don't think waiting longer will not help us in any way, but lead to >> split efforts on both branches, something that would in the end delay us >> on the way towards Qt 5. > >Are there people working on QtGui in the master branch? If so, that's the >most >important argument for me. I see 82 commits there since July 1st, which >is the >same number as QtCore. All merges from 4.8 go into master (and need testing there), plus we are doing additional work in merging master to refactor in regular intervals. > >> >I'd say at least Windows support needs to be on a decent state before >> >merging >> >is allowed. >> >> I can't see what we could gain from waiting. Qt 5 is right now in heavy >> development, it's not something to use in production yet. The merge will >> help as more people will use the code base. > >I see that stabilisation would be gained. The more we allow of unstable >code >in Qt 5, the harder it will be to get it to releasable state. Just >remember >the state of the p4 main branches during 4.4 and 4.5 times, before the CI >gate. Yes, stabilization is needed. But the refactor branch is in a relatively good shape on xcb showing that the platform independent code is ok. > >> >I'd also like to see a commitment to reaching feature parity and >>platform >> >support in the new code by the 5.0 feature freeze. >> >> From whom do you want that commitment? I assume you mean Nokia here. > >I meant "whoever is making these changes". It doesn't matter which >company >they work for. If anyone wants to merge major changes, I want to see that >person or group provide a credible commitment to quality on the reference >platforms. Ok, I can agree to that :) > >I'm working on QUrl and I intend to provide that commitment when I ask >that my >code be merged. > >> Nokia won't commit to supporting all platforms Qt 4 currently supports, >> and that has been communicated before. The main platforms for Qt 5 are >> Linux (X11 and Wayland), Mac and Win. But whether all of them will reach >> the same quality level with 5.0 depends not only on Nokia. > >Those are the platforms I want: the reference platforms. Other platforms >will >depend on interested people showing up and doing some work. > >> >I'd say that we need for merging that: >> > - refactor branch be at "feature parity" with current master >> >> Not sure what you mean by that. Refactor is in many ways better than >> current master, containing many fixes to the multithreaded rendering in >> QML that we don't have other places as well as a cleaned up >>architecture. >> >> And we will get some regressions no matter how long we wait. Waiting too >> long will simply lead to us finding them too late. > >That's the assurance I wanted to know: that it's not noticeably worse >than the >current code. Sure, problems will be found, that's not the issue. > >> >- new features work as intended on all reference platforms >> >> I tend to disagree. There's currently 1.3 million lines of code in >> qtbase/src. A lighthouse platform plugin is less than 15k LOC. This >> basically means that the window system integration is around 1% of the >> code base. >> >> There's also lots of work we need to do in other modules like >>QtMultimedia >> and other places that requires refactor. >> >> Keeping everybody else that works on other parts of Qt (in qtbase or on >> top of it) and needs the refactor branch waiting for one port is >>wasting a >> lot of peoples time. > >Understood. I'm not opposed to it. I just want to be clear here: this is >asking for an exception to the minimum requirements of merging code ("it >works"). Yes it is. However in this case I believe it's justified because it brings us much closer to Qt 5 by having the biggest architectural changes in place. Any time spent on doing development assuming the old architecture is at least partially time we're loosing. Cheers, Lars > >> >And by the feature freeze: >> > - master reaches "feature parity" with 4.8 on all reference platforms >> >> It's the right goal, but it might require also some people/companies >> outside of Nokia to step up (and yes I know that's still a bit difficult >> right now...). > >Right. > >But if we come to the point where we're almost ready to release, but we >haven't reached this state yet, it's grounds for delaying the release >further >if there are people still working on the code. Even if it's just one >person >doing part-time job. > >So if anyone has deadlines they need Qt 5.0, they should invest in making >Qt >5.0 release-ready (by the community's definition of "release-ready"). _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
