[Development] Commercial LTS Qt 5.15.4 released

[Rui Oliveira]

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" <enmarantispam at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development