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.
> >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.
> >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.
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").
> >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").
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
