Wouldn't make releases GLP/commercial instead of commercial only solve
all the issues? Both of maintainers, and KDE.
Drop the "L" for 12 months. It would seem a compromise solution for me.
Anyhow, indeed, for me, the big problem was the awkward situation where
Qt 6 is basically unusable and FOSS users of Qt stopped having releases.
If this started with 6.2 where 6.2.3 was commercial only, but if there
was a path for 6.3, it would be fine.
Anyway, let's code.
Rui
Às 17:39 de 13/05/2021, Eike Hein escreveu:
May 13, 2021 4:42 PM, "NIkolai Marchenko" <enmarantis...@gmail.com> wrote:
The problem with kde maintaining this is that people who are switching to newer
qt versions can no
longer expect fixes done to this branch to exist in the newer qt. So bugs that
have been closed by
the community may reappear again in actual Qt as TQTC deems them irrelevant.
No, this is not the case.
The policy for our Qt tree is to only merge patches that have been reviewed and
approved upstream first. It's a collection of backports of relevant patches
that can demonstrate they affect an open source product (KDE or otherwise).
We're not interested in promoting further divergence, compromising the upstream
open source Qt project or, for that matter, driving the CLA/non-CLA issue as a
wedge between the two codebases.
The main awkward gap there is hypothetical patches that are relevant for 5.15.x
but, for technical reasons, cannot be approved and merged into Qt 6.x. We would
still only add them after they've gotten a review and approval on Gerrit,
whether they're merged to the tree we cannot see or not.
To make this work in general we were in a conversation with the Qt Company
before announcing the tree, to let them know that this is happening and why,
and so the Qt Company could confirm it would be doing the patch reviews to make
this work.
Once Qt releases the commercial-only 5.15.x releases as open source (the KDE
FreeQt Foundation agreement gives up to 12 months to do this) the patches in
the KDE tree will be rebased onto them.
To be clear, purely in terms of convenience, we would prefer if the 5.15.x LTS
releases were not commercial-only and this additional effort was not necessary,
as it's a distraction from producing value for our end-users. Obviously it's
not ideal that an open source developer caring for their end-users cannot
produce a Qt bugfix and bring it all the way to them via an official Qt release
and the standard distribution channels at the moment. So we're not going to do
anything that will make it more difficult to return to source code parity
between the editions, either, as that would be in conflict with this view.
I think it's everyone's collective expectation that this will all calm down a bit in
practice once the ecosystem moves onto 6.x, as the next 6.x+1 release should generally be
available before 6.x.y point releases flip into a commercial-only mode (keep in mind the
initial 6.x.y is still open source, not _all_ point releases are implicitly LTS).
Provided the QA is up to snuff and extra-patch-necessary is rare that will likely be an
acceptable rhythm, as distros have always balanced the scale on "do we bump or
backport this one key patch" situationally.
Best regards,
Eike Hein
-
KDE, Plasma hacker
KDE e.V. Vice President
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
