Re: [Development] Fwd: Removing Qt 3D from release configuration in dev branch

[Tuukka Turunen via Development]

Hi,

Maintainers of Qt modules are listed at: https://wiki.qt.io/Maintainers and my 
understanding is that the current Qt 3D maintainers would continue. Module 
maintainership as such is not tied in a module being part of the release 
configuration or not.

I fully agree that having the module life-cycle better defined would be 
beneficial. It is also easier for everyone to add a new module as an add-on 
when it is also known how to retire it. Related to this topic we have a draft 
QUIP about module life-cycle in the works since a long time: 
https://codereview.qt-project.org/c/meta/quips/+/246320

Yours,

Tuukka

From: Björn Strömberg 
Date: Thursday, March 28, 2024 at 10:06
To: Tuukka Turunen 
Cc: Qt Project Development , Qt3D-Dev 

Subject: Re: [Development] Fwd: Removing Qt 3D from release configuration in 
dev branch
Hello Tuukka,

thanks for your answer.

In my view, as long as the 'rules' for the module(s) is clearly defined, as in 
this case say if KDAB takes over the official maintainer role,
while it still lives under the QtC infra roof, and we still get the modules 
dropped with the other sub-modules, then it will be business as usual,
but downstream has to get some kind of info channel on these kinds of things, 
are there more modules where this kind of thing happens?

one simple downstream info solution could be a small public repo or a 
news/rss-feed with only the important information as a kind of decision history,
say any change in the rules for a sub-module gets a record.

example on spectrum on the support on modules: [unmaintained, deprecated, 
life-support, full-maintenance, feature-development]

in my view there should be a better way to communicate the support level in the 
documentation as well,
this page https://doc.qt.io/qt-6.6/qtmodules.html should list some kind 
spectrum of support for the modules in the table,
I've always assumed everything on that list is what QtC has committed to 
support for the full major version life-cycle if its defined there.
for example any deprecation warning about other modules that supersede for 
'most use-cases',
preferably with some kind of examples of the use-cases where the other 
alternative is better, should definitely be listed here: 
https://doc.qt.io/qt-6.6/qt3d-index.html
because on that page there is not a word about anything being anything but 
sunshine and progress forward from Qt5 to Qt6 towards the future.

so i guess the only thing left is to see what KDAB will communicate in terms of 
keeping the lights on the modules support level spectrum,
like earlier mentioned list. personally i hope for more than life-support 
during the rest of 6.x.

/Björn


On Thu, Mar 28, 2024 at 7:40 AM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:
Hi Björn,

In general, we want to provide longevity and still host many items that are 
long ago removed from the main product configuration (or never been part of 
it). That said, we also need to have a way to sometimes let go of items in the 
main product configuration. Platform support is perhaps one of the most 
prominent examples of this, but sometimes also add-ons need to be adjusted. In 
some ways it is perhaps better not to drop things between major versions only. 
Maybe there is no good time, but at least during the transition from Qt 5 to 6 
we got a lot of feedback about not bringing some modules forward in Qt 6.0.

Qt is modular by structure and the official release is the split source 
packages: https://download.qt.io/official_releases/qt/6.6/6.6.3/submodules/. Of 
course, for users no longer having some functionality is a problem, so to the 
extent possible we want to keep things available and working also for those 
repositories that are not part of the release configuration (and there are many 
available at https://code.qt.io).

We can definitely keep Qt 3D available in the repositories, covered by code 
review, continue running CI and open for new commits. Like you said, eventually 
it is up to the module’s maintainers how well the code continues to run with 
new versions (or in case existing ones one day wish to step down, finding a new 
ones). Unless there is some bigger change preventing it, I would also wish to 
see Qt 3D continue to be available in the repositories throughout the whole Qt 
6 life-cycle, even beyond.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Björn Strömberg 
mailto:bjorn.stromber...@gmail.com>>
Date: Thursday, March 28, 2024 at 04:38
To: Qt Project Development 
mailto:development@qt-project.org>>, Qt3D-Dev 
mailto:qt3d-...@kdab.com>>
Subject: [Development] Fwd: Removing Qt 3D from release configuration in dev 
branch
accidentally replied only to Tuukka (QtC).

forwarding to ML so it gets where it was supposed to be.


to be clear, the problem is the admission of support, its left open, i saw that 
Giuseppe from KDAB also was on that bal

Re: [Development] Fwd: Removing Qt 3D from release configuration in dev branch

[Tuukka Turunen via Development]

Hi Björn,

In general, we want to provide longevity and still host many items that are 
long ago removed from the main product configuration (or never been part of 
it). That said, we also need to have a way to sometimes let go of items in the 
main product configuration. Platform support is perhaps one of the most 
prominent examples of this, but sometimes also add-ons need to be adjusted. In 
some ways it is perhaps better not to drop things between major versions only. 
Maybe there is no good time, but at least during the transition from Qt 5 to 6 
we got a lot of feedback about not bringing some modules forward in Qt 6.0.

Qt is modular by structure and the official release is the split source 
packages: https://download.qt.io/official_releases/qt/6.6/6.6.3/submodules/. Of 
course, for users no longer having some functionality is a problem, so to the 
extent possible we want to keep things available and working also for those 
repositories that are not part of the release configuration (and there are many 
available at https://code.qt.io).

We can definitely keep Qt 3D available in the repositories, covered by code 
review, continue running CI and open for new commits. Like you said, eventually 
it is up to the module’s maintainers how well the code continues to run with 
new versions (or in case existing ones one day wish to step down, finding a new 
ones). Unless there is some bigger change preventing it, I would also wish to 
see Qt 3D continue to be available in the repositories throughout the whole Qt 
6 life-cycle, even beyond.

Yours,

Tuukka

From: Development  on behalf of Björn 
Strömberg 
Date: Thursday, March 28, 2024 at 04:38
To: Qt Project Development , Qt3D-Dev 

Subject: [Development] Fwd: Removing Qt 3D from release configuration in dev 
branch
accidentally replied only to Tuukka (QtC).

forwarding to ML so it gets where it was supposed to be.


to be clear, the problem is the admission of support, its left open, i saw that 
Giuseppe from KDAB also was on that ball, what happens after 6.8, its only 
listed as supported
· Even though not part of the release configuration, intention is to 
keep Qt 3D working also with Qt 6.8

the wording I'm looking for is 'working with Qt at-least until 7.0' and when 
that wording comes into play, it can just as well still be left where it's in 
dev..

so we got a train wreck incoming, that likely will be QtC pushing this over to 
KDAB after 6.8, so how long after a 6.x release is it acceptable that the 
release of the Qt3D module releases, will QtC still host the tarballs,
will the development be done on Qts git trees?

that is really a question that it seems that only KDAB can answer since it 
seems that QtC is pushing it over to them without actually saying it open, but 
any lag upstream gets even bigger on the way downstream...

/Björn

>> first mail that went wrong
From: Björn Strömberg 
mailto:bjorn.stromber...@gmail.com>>
Date: Thu, Mar 28, 2024 at 2:53 AM
Subject: Re: [Development] Removing Qt 3D from release configuration in dev 
branch
To: Tuukka Turunen mailto:tuukka.turu...@qt.io>>

So now qt-6.x is effecively only promise backwards-compatible module wise to 
6.8?

As written it's open to interpretion afterwards...

Or will a breaking change in dev vs Qt3D really enforce no release of next 
point release unless the ext module actally is API compatible with the new 6.x 
minor?
Its unclear from the mail.

This sounds like it will become a "he said, she said" type of thing between QtC 
and KDAB, when stuff starts tilting...

In clear words can a Qt6 released module be dropped before Qt-7.0?

I might read the text like "the devils advocate" and look for errors, but since 
the shitty thing with the LTS release of patch releases as open source from 
Qt-5.15 forward, I dont trust these "stealth" changes, from user of the 
libraries perspective, its the reason i now follow the dev ml to get info about 
it before getting bitten.

Personally i was about to use qt3d in a new project since it was shipped as a 
module without any deprecation warnings in Qt6, so i assumed life of it till 
7.0 without hassle.

But now i will look outside the Qt Eco system for alternative designs before 
deciding path to take for end design.

I might even ditch the whole Qt subsystem in due time, or atleast design for 
the possibility.

If this is allowed once what will be the next thing that gets dropped?
 First was open source LTS support, now Qt3d is on the chopping blocks, so that 
makes module support uncertain. Due to the combination.

With kind regards
Björn

On Wed, 27 Mar 2024, 09:40 Tuukka Turunen via Development, 
mailto:development@qt-project.org>> wrote:
Hi,

We have been discussing with KDAB about the future maintenance of Qt 3D module. 
It is a quite large and complex module, which has for most use cases by now 
been superseded by Qt Quick 3D. Since Qt 3D h

Re: [Development] Removing Qt 3D from release configuration in dev branch

[Tuukka Turunen via Development]

From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Date: Wednesday, March 27, 2024 at 14:30
To: development@qt-project.org 
Subject: Re: [Development] Removing Qt 3D from release configuration in dev 
branch
Hi,

On 27/03/2024 09:39, Tuukka Turunen via Development wrote:
> # Qt 3D module is removed from official release configuration in the dev
> branch, i.e. no longer part of the releases from Qt 6.8 onwards
> # Qt 3D continues to be part of Qt project, it continues to be covered by
> CI, and available in the repository for those who want to use it
> # Even though not part of the release configuration, intention is to keep
> Qt 3D working also with Qt 6.8
> # Qt 6.7 and older releases continue to have Qt 3D module in the upcoming
> patch releases

Thank you for the heads-up. I think this should eventually become a blog
post, a changelog note in 6.7, and needs some documentation notes --
users deserve to be notified visibly in advance.
TTT: Yes, we should notify users about this. Release notes of Qt 6.7.x as well 
as Qt 3D documentation is probably the best place. Blog is quite active, but 
still only a fraction of users follow it, so that is less effective than docs 
and release notes.


There is still a number of aspect that IMHO need to be addressed:

* If Qt3D is not bundled with the Qt installer, how are users going to
install it? I'd really want a very practical solution; ideally a CMake
command that does everything (for instance: is Qt3D found in your Qt
build? Then use it, otherwise fetch+build "the right version" from
sources.).
TTT: That would be good to sort out in general for the multiple items in the Qt 
project repositories that are not part of the release configuration of Qt. For 
those releases Qt 3D is still part of it would continue to show Qt 3D in the 
installer. But for dev and Qt 6.8 snapshots it would do longer be included at 
the point when it is removed from the release configuration.

* What branching and release model is Qt3D going to have? Is it still
promising API/ABI compat in the future? Will it evolve towards a more
complicated model like Webengine?
TTT: It is part of multiple currently active releases (Qt 6.2. Qt 6.5, Qt 6.6 
and Qt 6.7), so we would need to ensure things continue to work for picking 
changes from dev to these. These can be done from dev, so new branches would 
not be needed.


* Is Qt3D going to be under Qt's CI *after* 6.8?

TTT: Yes. It should be covered by CI at least until no longer needed as part of 
supported releases, but I don’t see any reason why it could not be in CI also 
after that, if so desired.
Yours,
Tuukka


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, 
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kdab.com%2F=05%7C02%7Ctuukka.turunen%40qt.io%7Cbc5cff0d9a3d42a23f8608dc4e59add3%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638471394283069491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ZwkjomJC0M%2BLRGobkyr%2BaUc7o74guTO3KVwtEjy3%2FQo%3D=0<http://www.kdab.com/>
KDAB - Trusted Software Excellence
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Removing Qt 3D from release configuration in dev branch

[Tuukka Turunen via Development]

Hi,

We have been discussing with KDAB about the future maintenance of Qt 3D module. 
It is a quite large and complex module, which has for most use cases by now 
been superseded by Qt Quick 3D. Since Qt 3D has been available for a long time, 
it should continue to be available for those who still need it. It is also part 
of all currently supported releases, which would continue to have it in 
upcoming patch level releases.

After discussing with KDAB (maintainer of Qt 3D) on how to proceed, we came up 
with the following and also agreed that I’ll summarize it for the Qt project 
development list:

  *   Qt 3D module is removed from official release configuration in the dev 
branch, i.e. no longer part of the releases from Qt 6.8 onwards
  *   Qt 3D continues to be part of Qt project, it continues to be covered by 
CI, and available in the repository for those who want to use it
  *   Even though not part of the release configuration, intention is to keep 
Qt 3D working also with Qt 6.8
  *   Qt 6.7 and older releases continue to have Qt 3D module in the upcoming 
patch releases
Qt 3D module was initially developed for Qt 4 and then received a major 
overhaul for Qt 5. It was also brought forward to Qt 6. Initially the idea was 
to offer Qt 3D as a separate item in Qt 6.0 via package manage 
(https://wiki.qt.io/Qt_6.0.0_Modules), but since we were not able to make this 
modularity successful, it was included to the release configuration along with 
the other add-on modules. Qt Quick 3D is a later addition to Qt, originating 
from the contribution from NVIDIA 
(https://www.qt.io/blog/2017/02/20/introducing-qt-3d-studio), initially as a 
separate runtime, then refactored into Qt Quick 3D for Qt 5 to achieve better 
alignment with Qt Quick 2D and after that completely reworked to be fully 
aligned with Qt Quick in Qt 6.

Yours,

Tuukka




-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Decrease amount of qt releases in online installer

[Tuukka Turunen via Development]

Hi,

For the open-source online installer where mirorbrain is used.

The commercial distribution is done with a different system where mirror space 
is not an issue and there is a much higher number of “mirrors”, so also the 
archive performance is a bit better.

Yours,

Tuukka

From: Development  on behalf of Tomasz 
Siekierda 
Date: Thursday, February 22, 2024 at 15:50
To: Jani Heikkinen 
Cc: development@qt-project.org 
Subject: Re: [Development] Decrease amount of qt releases in online installer
On Wed, 21 Feb 2024 at 11:44, Jani Heikkinen via Development 
mailto:development@qt-project.org>> wrote:
Hi,

Currently, more than 60 Qt releases can be installed from the Qt open source 
online installer (if all installation categories are selected). This requires a 
huge amount of disk space on the mirrors and also causes some performance 
issues with the online installer. That's why I suggest removing the older ones 
from the online installer; these releases can still be found in the archive as 
source packages and offline installers.

But what are the ones that can be removed? I suggest removing all Qt 5 except 
Qt 5.15.x. And maybe we could also remove the oldest Qt6s, e.g. all Qt 6.0.x, 
6.1.x?


Is this only about Open Source installer or also Commercial one? I'm on Qt 
5.12.5 (Commercial) and will continue using this version potentially for years 
to come (yeah it sucks but it's not my choice). So it would be nice to still 
have it in the installer. I can compile it myself, I know I know, but the 
installer is just a lot more convenient.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Decrease amount of qt releases in online installer

[Tuukka Turunen via Development]

Hi,

This is a good change. It has been a long time since we previously cleaned the 
releases available via the online installer, so the number has been growing to 
be quite large.

In general we should be always guiding users towards the latest releases and to 
large extent users are doing that. We should also be even faster that currently 
transferring the unmaintained releases to the archive, which in turn likely 
causes more that today use of the archive (of the online installer), so 
removing very old ones from the online installer is beneficial.

Mirrors make their own decisions on what they mirror, but Qt repositories are 
large so keeping the size of the online installer repo in control means it will 
have better mirror coverage. When the size grows too big, we tend to lose 
mirrors.

Yours,

Tuukka

From: Development  on behalf of Jani 
Heikkinen via Development 
Date: Wednesday, February 21, 2024 at 13:34
To: Giuseppe D'Angelo , development@qt-project.org 

Subject: Re: [Development] Decrease amount of qt releases in online installer
> -Original Message-
> From: Development  On Behalf Of
> Giuseppe D'Angelo via Development
> Sent: keskiviikko 21. helmikuuta 2024 13.21
> To: development@qt-project.org
> Subject: Re: [Development] Decrease amount of qt releases in online installer
>
> Hello,
>
> On 21/02/2024 11:42, Jani Heikkinen via Development wrote:
> > Currently, more than 60 Qt releases can be installed from the Qt open
> > source online installer (if all installation categories are selected).
> > This requires a huge amount of disk space on the mirrors and also
> > causes some performance issues with the online installer.
>
> What kind of performance issues are we talking about?

It takes quite a time to show all releases when you select  'archive'  
category. With latest online installer this is already much better than earlier 
but it still takes some time and it's a bit annoying...

>
> > That's why I suggest
> > removing the older ones from the online installer; these releases can
> > still be found in the archive as source packages and offline installers.
> >
> > But what are the ones that can be removed? I suggest removing all Qt 5
> > except Qt 5.15.x. And maybe we could also remove the oldest Qt6s, e.g.
> > all Qt 6.0.x, 6.1.x?
> >
> > Any objections or other opinions?
> >
>
> Do you have data on how what's the share of downloads per Qt version / OS?
> Maybe those can be mirrored less aggressively?

I don't have that kind of data in my hands now but it isn't that easy to choose 
mirroring strategy based on the release; releases aren't in one folder in 
online installer and so on it would be quite hard for mirrors to define which 
repos (==folders) should not be mirrored.

- Jani

--
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

[Development] Update What's new in Qt 6.7 (Was: Re: HEADS-UP: Qt 6.7 Feature Freeze)

[Tuukka Turunen via Development]

Hi,

There is quite a lot of things missing still from 
https://codereview.qt-project.org/c/qt/qtdoc/+/524057

Qt 6.7 Beta 1 release is somewhere early next week and we should publish the 
first iteration of the What’s new page along with it.

Yours,

Tuukka


From: Development  on behalf of Volker 
Hilsheimer via Development 
Date: Saturday, December 9, 2023 at 16:07
To: Jani Heikkinen , development@qt-project.org 

Subject: Re: [Development] HEADS-UP: Qt 6.7 Feature Freeze
> On 8 Dec 2023, at 15:06, Jani Heikkinen via Development 
>  wrote:
>
> Hi!
>  Qt 6.7 Feature Freeze will be in effect today. If your changes are ready and 
> approved by the end of today, you can still continue staging those in 'dev' 
> over the weekend. The plan is to branch from "6.7" to "dev" on Monday morning 
> next week.

Perhaps we should wait with branching off until we have a successful dependency 
round completed in dev. Otherwise the CI system will do twice the work to test 
the same set of changes in different branches.

>  If your feature isn't ready by the end of today, you'll either need to 
> postpone it to Qt 6.8 or request an exception.

If your feature is ready and merged, please remember to update the 
whatsnew67.qdoc file in the qtdoc repository as well.

To limit conflicts, use gerrit’s inline editing feature to add your bits to 
this change:

https://codereview.qt-project.org/c/qt/qtdoc/+/524057


Volker

--
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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Tuukka Turunen via Development]

Hi,

Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).

That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.

So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.

Yours,

Tuukka

From: Development  on behalf of Thiago 
Macieira 
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs
On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
> archives.
>
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But I said:

> I am, however, questioning the design of the API that Dominik presented.

There have been zero other discussions of "genivi" since then
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dgenivi%2Bsite%25253Ahttps%25253A%25252F%25252Flists.qt-project.org%25252Fpipermail%25252Fdevelopment%25252F=05%7C01%7Ctuukka.turunen%40qt.io%7Cc5d9d74e44014c5e22c308dbf5b48c59%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638373928019928582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=r0fpIXCgLTyWGtC9bIJ9waV7QgvH6J%2FnwRLJ%2BZMPL9k%3D=0

I don't know what kind of API reviews have been done since. But there has been
no discussion about renaming this module. Therefore, the name it is currently
using is unauthorised and does not imply a precedent.

-1 on this new module with this name.


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Meeting minutes from Qt Release Team meeting 20.06.2023

[Tuukka Turunen via Development]

Hi,

Still on its way, there were a couple of items found during testing and new 
packages with those fixes needed to be built (and now new test round ongoing).

Probably early next week, but anyways as soon as possible.

Yours,

Tuukka

From: Development  on behalf of Ilya Fedin 

Date: Monday, 3. July 2023 at 17.43
To: development@qt-project.org 
Subject: Re: [Development] Meeting minutes from Qt Release Team meeting 
20.06.2023
On Tue, 20 Jun 2023 14:12:25 +
Jani Heikkinen via Development  wrote:

> Qt 6.5 status:
>
> -  Branching from '6.5' to '6.5.2' done
>
> - Qt 6.5.2 content is not frozen yet. The target is to freeze the Qt
> 6.5.2 content later this week
>
> - The target is to release Qt 6.5.2 Wed 28th June

What has hapenned to the 6.5.2 release? It's already 3rd July but
there's no release, no task in Jira and no changes on the Qt 6.5
Release page on the wiki. 6.5.2 release is important as it fixes
crashes with gesture management on X11 and Wayland and for X11 it
(hopefully) should be first good release in Qt 6 series as X11 had
scrolling problems all the Qt 6 lifetime and the release fixing it
crashes on gestures.
--
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

Re: [Development] Raising the minimum to C++20

[Tuukka Turunen via Development]

Hi,

I also agree that it is important to keep moving along and harness what new C++ 
versions offer in the best way we can. Potential time to do this would indeed 
be in the near future – one good point in time to drop support for older 
compilers could be with Qt 6.9 around March 2025 as mentioned. Like Volker said 
we should assess both C++20 and C++23 at that point.

The topic raised by at least Maurice about the embedded and especially RTOS 
platforms moving slower is very valid. But these are also ones where customers 
typically stay with one Qt version for a bit longer. Thus, I believe it could 
work to have Qt 6.8 (LTS) as the last one that compiles with C++17. As long as 
there is some new compiler and RTOS combination that we can keep running on dev 
with the new C++ version (20 or 23) we can pick/backport the relevant fixes to 
Qt 6.8 for a while until it is again a good time to support the RTOS platforms 
for deployment (optimally by the next LTS is due around September 2026).

Let’s continue assessing the benefits from using capabilities of later C++ 
versions and meanwhile check with the RTOS vendors on how they have been 
planning to enable using C++20 and C++23.

Yours,

Tuukka

From: Development  on behalf of Thiago 
Macieira 
Date: Friday, 5. May 2023 at 19.17
To: development@qt-project.org 
Subject: Re: [Development] Raising the minimum to C++20
On Friday, 5 May 2023 03:18:46 PDT Ville Voutilainen wrote:
> > Of the C++20 features I currently see a good reason to make mandatory:
> > * feature-test macros (no change: we're already using them)
> > * spaceship operator and  header
> > * char8_t
> > * std::is_constant_evaluated()
> > * constinit
> > *  header
> > * (maybe) designated initialisers
> > * (maybe) constexpr from  and 
>
> I don't see any of these as worth breaking embedded users who want new
> Qt versions but don't yet
> have the compilers that can give them these facilities.

When you put it this way, no, they're not worth *breaking* the experience for
those users. We're already using the feature-test macros and constinit even in
C++17 mode, we have our own implementation for what  does (but see
below). We also have conditional code for std::is_constant_evaluated() and a
fallback to a GCC extension, and Ivan was beginning to add a fallback/
workaround for the spaceship operator with macros[1]. The latter is why I
began this thread: I'd like to know if we should "dirty" our code with more
macros or if we can go clean for the spaceship.

The only odd result is that one compiler (MSVC) is generating worse code
because we don't have access to the builtins that  and
std::is_constant_evaluated() would have used. That's fixable.

One, __builtin_is_constant_evaluated() works with GCC 9, Clang 10, MSVC 2019
and even the old EDG-based Intel compiler in C++17 mode, see
https://gcc.godbolt.org/z/4boM5Esfx
So we *could* just use it and damn the torpedoes. That leaves out users of GCC
8 (a.k.a. QNX) and the GHS compiler, who would get non-constexpr code
generation.

Two, we could simply raise MSVC or just all Windows builds to C++20 regardless
of what we do elsewhere. During Qt 4 days, after we switched to C++11, we did
begin using some core language and standard library features without compiler
check in macOS-specific code because we knew the state of that compiler.

I think is a fair deal: we get to move forward and improve the platforms that
can upgrade, without affecting the ones that can't.


[1] https://codereview.qt-project.org/c/qt/qtbase/+/475447

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: let's change the release schedules a bit

[Tuukka Turunen via Development]

Hi,

We have not yet concluded about Jani’s proposal for adjusting the feature 
freeze and release timing: 
https://lists.qt-project.org/pipermail/development/2022-December/043380.html

The original proposal was: ”… release minor releases in April and October, that 
would allow us to move FF also after the holidays: So FF for April release 
would be in January and FF for October release would be in August.”

We should make the decision soon to set the dates for Qt 6.6 release. Do we 
keep the current approach or go forward with extending the Qt 6.6. feature 
freeze to be in August instead of June?

Yours,

Tuukka


From: Tuukka Turunen 
Date: Wednesday, 14. December 2022 at 11.44
To: Volker Hilsheimer , Jani Heikkinen 

Cc: development@qt-project.org 
Subject: Re: [Development] Proposal: let's change the release schedules a bit
Hi,

One of the main problems we face every time with the feature freeze is a lot of 
changes coming in just before the deadline. While this is quite natural as 
such, it does also cause some amount of instability and problems in getting the 
full integration test round completed regularly. There are many ways to tackle 
this issue and a lot of things have already been done (such as introducing a 
new freeze point for platforms/configurations in CI before the FF). Having the 
FF date just before a major holiday period is one item that possibly increases 
the instability. Not everyone is on vacation at the same time and especially 
during the summer different countries tend to have a bit different general 
preferences for the primary holiday period. Having the FF in January instead of 
December and August instead of June would likely reduce the number of changes 
coming in just before the deadline. Spreading the changes more evenly in the 
feature development timeline makes it easier to keep integration test rounds 
passing regularly.

Yours,

Tuukka


From: Development  on behalf of Volker 
Hilsheimer via Development 
Date: Thursday, 8. December 2022 at 14.03
To: Jani Heikkinen 
Cc: development@qt-project.org 
Subject: Re: [Development] Proposal: let's change the release schedules a bit
For me, the argument that Eddy makes is very strong: a milestone or deadline 
right after holidays has the potential of ruining those holidays, without 
giving any meaningful extra time to get features done.

Releases of operating systems have some relevance: new macOS and Windows 
versions have in recent cycles happened around March/April and 
October/November. But even if we try to have the Qt release shortly after those 
to claim quick support, in reality it would probably be “technology preview” 
status anyway, knowing how much time it takes to make new CI configurations 
significant. And TP status can just as well be achieved based on beta and 
preview versions. Linux distro cycles are more relevant to align with as we are 
upstream, but in practice I’d expect more practical value in having the first 
or second patch release in a distro. So in summary, I don’t think any of those 
need to have a strong influence on our .0 release timing.

What I don’t quite understand is why a long beta period is a problem. We get 
valuable feedback from community and customers during that, and I vaguely 
remember some reports of regressions coming in pretty late in the process, just 
before or even after the release candidate. I don’t know whether those reports 
came in late because users wait until things look almost ready (i.e. RC 
available), or because it simply takes time before enough users try out a beta. 
In the former case, a longer stabilization cycle makes no difference; in the 
latter case, we should rather make it longer.

Perhaps we have some data on that (how do download figures develop compared to 
tickets in JIRA reported against preview versions), but I haven’t seen anything 
that I’d consider conclusive. And without knowing, I don’t see much value in 
trying to optimize things either way. Eddy’s concern on the other hand is very 
tangible.


Volker





> On 7 Dec 2022, at 12:48, Jani Heikkinen via Development 
>  wrote:
>
> Hi!
>
>> Jani: what is the problem with that calendar interval's present length ?
> We need ~13 weeks (real working time) from the feature freeze to the final 
> release. Currently we have holidays during that period and so on we need to 
> reserve much longer calendar time for that. E.g. with Qt 6.5 this time is 
> planned to be a bit more than 15 weeks and with Qt 6.4 it was a bit more than 
> 16 weeks.
> For me this hasn't been a problem at all but I have heard some other opinions 
> as well; someone wants to finalize new things during holidays and someone 
> isn't that much in holiday e.g Christmas time. For those this would give few 
> weeks extra implementation time between the releases...
>
>>> I would sooner move the schedule half a month earlier - Nove

Re: [Development] New Qt example development guideline and revamping examples

[Tuukka Turunen via Development]

”The point of examples is to show how to use Qt to do specific things.  Some of 
them are redundant? Well there is not only one way to do things; why should we 
hide something cool just because it’s only the second of several choices? In 
the future I think we will hesitate to write new examples if the risk of 
deletion is so high. ”

On the contrary, target is to make the examples more useful by ensuring all 
examples follow the best practices and improving how they are shown in 
documentation and creator welcome page. No-one want to delete examples that are 
good and useful for our users.

The list I sent is examples that are currently not shown in docs or creator, so 
users are not that likely to find them. We should also think why these examples 
are not shown? Typically this is not by accident, but it has been determined 
that it is better to hide the example.

The list contains 113 examples, so I am sure there are some that would be 
better to fix to meet the example guideline, write the documentation and show 
the example. But for many of these the value as an example is low. Thus is 
better to move to manual tests in case we need it for testing purposes.

Yours,

Tuukka

From: Development  on behalf of Shawn 
Rutledge via Development 
Date: Friday, 3. February 2023 at 15.56
To: Qt Development 
Subject: Re: [Development] New Qt example development guideline and revamping 
examples

On 3 Feb 2023, at 13:56, Tuukka Turunen via Development 
 wrote:

pdf/pdfviewer

Depends which one you mean.  They are all new and maintained at this point.  
There is some redundancy on purpose, because there are multiple PDF-viewing 
components.  So I wouldn’t delete any of them.


quick/delegatechooser

We need to make sure we are showing DelegateChooser somewhere; it’s quite 
useful.  I don’t see it in any other examples.


quick/pointerhandlers

I plan to give the pointerhandlers example some proper docs.  It only recently 
graduated from being a manual test.  It may not look like a “proper desktop 
application” but that’s not the point.

… many more I don’t remember so well, and then...
wayland/custom-extension
wayland/custom-extension/compositor
wayland/custom-extension/cpp-client
wayland/custom-extension/qml-client
wayland/custom-shell/client-plugin
wayland/custom-shell/compositor
wayland/hwlayer-compositor
wayland/minimal-cpp
wayland/server-buffer
wayland/server-buffer/compositor
wayland/server-buffer/cpp-client
widgets/itemviews/flattreeview
widgets/itemviews/storageview
...


As Kimmo mentioned, we should aim to check and move (or remove if not seen 
relevant as a manual test by the module maintainer) these during February.

You are talking about removing them from the manifest, not removing the code, I 
hope? Even so...

The point of examples is to show how to use Qt to do specific things.  Some of 
them are redundant? Well there is not only one way to do things; why should we 
hide something cool just because it’s only the second of several choices?

In the future I think we will hesitate to write new examples if the risk of 
deletion is so high.

Move them to manual tests?  Well that’s better than deleting, but users will 
not tend to find those, because we don’t ship them.

Snippets? I think those should be complete enough to actually run.  Otherwise 
it’s too much work to keep re-verifying that they still work.  And it is more 
useful to users to start with a complete, minimal example that already runs, 
and then add the extra functionality that they want, rather than just some 
stanza of code that got broken at some point along the way.  With QML that’s 
not too hard; so my rule is every QML snippet should be a complete standalone 
file that can run with the qml tool.  But with C++ snippets it’s not convenient 
to make them runnable; so when we convert C++ examples to snippets, we can 
expect them to rot, unless we come up with a way to auto-wrap them with 
boilerplate and test them automatically on a periodic basis (in CI, in 
pre-release testing or whatever).

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt example development guideline and revamping examples

[Tuukka Turunen via Development]

Hi,

…and in case unsure what is shown in docs & Creator, it is the ones listed in 
the manifest file as described at 
https://doc.qt.io/qt-6/26-qdoc-configuration-example-manifest-files.html and 
https://wiki.qt.io/Qt_Examples_in_Qt_Creator

Mostly these are examples that have not been deemed relevant to show to the 
users in docs and Creator, often ones that would take quite an effort to update 
according to the guideline.

Rough listing of these:

activeqt/simpleqml
applicationmanager/application-features/imports/terminator2
applicationmanager/application-features/native/widgets
applicationmanager/startup-plugin
charts/chartinteractions
charts/qmlboxplot
charts/qmlcandlestick
charts/qmlpiechart
core5/widgets/tools/codecs
corelib/bindableproperties/bindablesubscription
corelib/bindableproperties/subscription
corelib/permissions
corelib/tools/customtypesending
dbus/remotecontrolledcar
embedded/digiflip
embedded/flickable
embedded/flightinfo
embedded/lightmaps
embedded/raycasting
embedded/styleexample
ifvehiclefunctions/window-qml
interfaceframework/qface-remote/demo
interfaceframework/qface-remote/frontend
interfaceframework/qface-remote/server_qtro
location/geojson_viewer
mqtt/consolepubsub
mqtt/quickpublication
multimedia/audiodecoder
multimedia/devices
network/dnslookup
network/multistreamclient
network/multistreamserver
oauth/redditclient
oauth/twittertimeline
opcua/waterpump/simulationserver
opengl/computegles31
opengl/contextinfo
opengl/hellowindow
opengl/paintedwindow
opengl/qopenglwidget
opengl/qopenglwindow
opengl/threadedqopenglwidget
pdf/pdfviewer
qml/qmldom
qml/shell
qmltest/qmltest
qpa/qrasterwindow
qpa/windows
qt3d/3d-text
qt3d/anaglyph-rendering
qt3d/compute-particles
qt3d/controls
qt3d/controlsunderlay
qt3d/instanced-arrays-qml
qt3d/lights
qt3d/phong-cubes
qt3d/qardboard
qt3d/qgltf
quick/customitems/maskedmousearea
quick/delegatechooser
quick/customitems/scrollbar/scrollbar.pro
quick/customitems/tabwidget/tabwidget.pro
quick/embeddedinwidgets
quick/multieffect/itemswitcher
quick/multieffect/testbed
quick/particles/itemparticle
quick/pointerhandlers
quick/scenegraph/threadedanimation
quick3d/helloqtquick3d
quick3d/offlineshaders
remoteobjects/ble/bleclient
remoteobjects/ble/bleserver
remoteobjects/clientapp
remoteobjects/cppclient
remoteobjects/plugins
remoteobjects/remoteobjects_server
remoteobjects/simpleswitch/directconnectclient
remoteobjects/simpleswitch/directconnectdynamicclient
remoteobjects/simpleswitch/directconnectserver
remoteobjects/simpleswitch/registryconnectedclient
remoteobjects/simpleswitch/registryconnectedserver
remoteobjects/ssl/sslcppclient
remoteobjects/ssl/sslserver
remoteobjects/websockets/wsclient
remoteobjects/websockets/wsserver
sensors/grue/console_app
sensors/grue/plugin
serialport/receiver
serialport/sender
spatialaudio/audiopanning
svg/draganddrop/delayedencoding
svg/embedded/desktopservices
svg/embedded/fluidlauncher
svg/embedded/weatherinfo
svg/embeddedsvgviewer
wayland/custom-extension
wayland/custom-extension/compositor
wayland/custom-extension/cpp-client
wayland/custom-extension/qml-client
wayland/custom-shell/client-plugin
wayland/custom-shell/compositor
wayland/hwlayer-compositor
wayland/minimal-cpp
wayland/server-buffer
wayland/server-buffer/compositor
wayland/server-buffer/cpp-client
widgets/itemviews/flattreeview
widgets/itemviews/storageview
widgets/scroller/graphicsview
widgets/tools/plugandpaint
widgets/windowcontainer
xml/htmlinfo
xml/rsslisting

As Kimmo mentioned, we should aim to check and move (or remove if not seen 
relevant as a manual test by the module maintainer) these during February.

Yours,

Tuukka

From: Development  on behalf of Kimmo 
Leppälä via Development 
Date: Friday, 3. February 2023 at 9.03
To: development@qt-project.org 
Subject: Re: [Development] New Qt example development guideline and revamping 
examples
Hi,

There has been slight modifications to the guideline document 
https://wiki.qt.io/Qt6/Example-Guideline


Most important change being that the examples that are not shown in Qt 
documentation should be moved under tests/manual/examples. This cleanup should 
be done preferably during February so that we have cleared away the examples we 
don’t want to revamp at this point.

Thanks!

-Kimmo

On 19.1.2023, 9.25, "Kimmo Leppälä"  wrote:

Hi,

Thank you for the proposals Giuseppe!

On 18.1.2023, 14.14, "Development"  wrote:

On 18/01/2023 10:51, Kimmo Leppälä via Development wrote:
> Also, the guideline is a living document in wiki and we would be happy
> to hear feedback and proposals for it!
>

Here's a few considerations:


>  RECOMMENDED
> Consider also compiling with the more strict warning flags and fix any issues 
> they reveal.

As history shows, this is not going to happen unless we enforce it. The
cmake-magic macros that are used to build examples should set those more
strict flags and enforce them (-Werror).


> Clang
> Use -Weverything compiler parameter
> Visual Studio
> Use /Wall 

Re: [Development] New Qt example development guideline and revamping examples

[Tuukka Turunen via Development]

Hi,

Yes, intention is to improve also the application / project examples in qtdoc 
repo. In addition to the Qt 6 best practices, these could also get a bit of 
visual or functionality polish. Problematic or unnecessary existing examples 
could be removed. Intention is also to adjust how the examples are categorized 
and thus provide these ones more towards the user (e.g. top of the Creator 
welcome page). Some selected examples from other repos could be moved to qtdoc 
and extended.

See: https://bugreports.qt.io/browse/QTBUG-108751 for planning related to the 
qtdoc examples.

Note that while qtdoc has these example apps under ‘examples/demos’ folder, 
they are still in principle examples of how to use Qt to make an application.

Yours,

Tuukka

From: Development  on behalf of Rui 
Oliveira 
Date: Wednesday, 18. January 2023 at 12.14
To: development@qt-project.org 
Subject: Re: [Development] New Qt example development guideline and revamping 
examples

Hello,

I'd like to point to https://bugreports.qt.io/browse/QTBUG-100100 where you can 
read:

"Ah, those examples are in the qtdoc repository, where nobody looks at them..."
"Back when we worked on QTBUG-98130, we forgot to add the examples in qtdoc to 
the list."

Are these going to receive love as well? I don't like to see scattered stuff 
diverge...

Thanks,
Rui
Às 09:37 de 18/01/2023, Kimmo Leppälä via Development escreveu:
Hi,

We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) 
to follow the new example development guideline: 
https://wiki.qt.io/Qt6/Example-Guideline.
Target is to go through all the ~600 examples and either modify according the 
guideline or remove, if the example is obsolete or redundant and complete this 
activity by the end of June 2023.

Cheers,
Kimmo Leppälä




___

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

Re: [Development] New Qt example development guideline and revamping examples

[Tuukka Turunen via Development]

Hi,

Typically pick to 6.5 as the examples like documentation is unproblematic to 
update.

Yours,

Tuukka

From: Development  on behalf of Ivan 
Solovev via Development 
Date: Wednesday, 18. January 2023 at 12.09
To: development@qt-project.org , Kimmo Leppälä 

Subject: Re: [Development] New Qt example development guideline and revamping 
examples
Hi,

Should the example updates be picked to 6.5, or is it only a 6.6 thing?
Is there any general guideline from the Release Team?

Best regards,
Ivan

From: Development  on behalf of Kimmo 
Leppälä via Development 
Sent: Wednesday, January 18, 2023 10:51 AM
To: development@qt-project.org 
Subject: Re: [Development] New Qt example development guideline and revamping 
examples


Also, the guideline is a living document in wiki and we would be happy to hear 
feedback and proposals for it!



-Kimmo



From: Kimmo Leppälä 
Date: Wednesday, 18. January 2023 at 11.37
To: development@qt-project.org 
Subject: New Qt example development guideline and revamping examples

Hi,



We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) 
to follow the new example development guideline: 
https://wiki.qt.io/Qt6/Example-Guideline.

Target is to go through all the ~600 examples and either modify according the 
guideline or remove, if the example is obsolete or redundant and complete this 
activity by the end of June 2023.



Cheers,

Kimmo Leppälä


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Development]

Hi,

One more thing to note related to 10.15 support in Qt 6.5 is that even if it is 
dropped from the supported platforms (as has been planned), it doesn’t mean it 
would be impossible for someone to use it in their application. Of course, 
deploying to an unsupported version means more testing and possibly some fixes 
to be picked. It is never recommended to run on a non-tested (in CI) 
configuration, but doing the testing for the application is still an option. 
That said, staying for a while with Qt 6.4.x is another option for those who 
still need to support 10.15 during next year.

Yours,

Tuukka



From: Development  on behalf of Vladimir 
Belyavsky 
Date: Friday, 23. December 2022 at 11.54
To: development@qt-project.org 
Subject: Re: [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac 
Desktops
For my company, dropping support for macOS 10.15 in Qt 6.5 is also problematic,
as we'll have to stick with Qt 6.4 or consider dropping support and updates for 
about 15% of our users.

Here are our internal statistics on the current macOS distribution to real 
average users,
based on a really large number of customers:
- macOS 10.14.6 ~ 5% (fortunately Qt 6.3.2  it's still functional there)
- macOS 10.15.7 ~ 10%

As a developer, I understand the reason for stopping legacy OS support,
but it will not be easy for me to explain to the management why we once again
should stop supporting quite a large number of our users. (they are still angry 
after dropping Win7)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Development]

… and like the first line states, the telemetry functionality of Qt Creator is 
based on https://api.kde.org/frameworks/kuserfeedback/html/index.html

On the end user application analytics topic there is work ongoing to build a 
new product called Qt Insight, but that is currently not for open-source 
applications. You can learn more about Qt Insight at 
https://www.qt.io/product/insight

Yours,

Tuukka


Lähettäjä: Cristian Adam 
Lähetetty: maanantaina, joulukuuta 19, 2022 5:58 ip.
Vastaanottaja: Michael Jackson ; Tuukka Turunen 
; Macieira, Thiago ; 
development@qt-project.org ; 
inter...@qt-project.org 
Aihe: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

Hi,

See qt-creator/plugin-telemetry.git - A plugin that collects usage data from Qt 
Creator users. This data is used to improve the Qt user experience and is one 
information source for product 
decisions.<https://code.qt.io/cgit/qt-creator/plugin-telemetry.git/about/>

Cheers,
Cristian


From: Interest  on behalf of Michael Jackson 

Sent: Monday, December 19, 2022 16:47
To: Tuukka Turunen ; Macieira, Thiago 
; development@qt-project.org 
; inter...@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops


Dear Tuuka or any other QtCreator Developers,

I am interested in finding out more how QtCreator has implemented their 
telemetry system. We would also like to add this capability to our open-source 
software but this is our first foray into this kind of telemetry system. Maybe 
just a hint what what code bits to grep for in the source would get me started.



Thank You.

--

Mike Jackson



From: Interest  on behalf of Qt Interest 

Reply-To: Tuukka Turunen 
Date: Saturday, December 17, 2022 at 3:45 AM
To: "Macieira, Thiago" , 
"development@qt-project.org" , Qt Interest 

Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops



Hi,



Most of the macOS users are quite quick to take on new OS versions and this is 
true also for adoption of macOS versions with the new numbering scheme. Apple 
hardware is also rather good in keeping support for new OS versions and at 
least between versions 10.15 and 11 there does not seem to be a major drop in 
what HW is supported.



The challenge we have with supporting macOS versions is that some users migrate 
really quickly, so we need to work a lot with the unreleased (developer beta) 
versions in order to ensure Qt works well with the new macOS version optimally 
before it is even released for production. We also aim to keep supporting older 
versions and the ones in between. This means quite a lot of CI system load – 
especially as we now have both Intel and ARM architectures to test on.



There is also positive development happening. With the latest versions the 
virtualization support is improving so that we are hopeful to be able to use 
the hardware more efficiently (by running two virtual machines in each physical 
HW). So while macOS is still far from the convenience we have with Linux and 
Windows that support sever grade hardware, things are getting better with Macs 
as well going forward (not for 10.15, though).



Related to the usage of 10.15 one indication comes from Creator telemetry. 
Based of this roughly 8% of the macOS users this year have version 10.15. Of 
course, this is not a direct indicator for how many end users of Qt based apps 
there are with macOS 10.15, just how much of the developers using Creator have 
it. Telemetry is fully optional, but I think it is reasonable accurate for this 
type of data point as the OS version is unlikely to greatly affect sending or 
not sending the telemetry data. Note also that we have a lot of different Qt 
versions supporting macOS 10.15, and many applications are still using Qt 5.



Yours,



Tuukka



From: Interest  on behalf of Thiago Macieira 

Date: Saturday, 17. December 2022 at 1.20
To: development@qt-project.org , 
inter...@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

On Friday, 16 December 2022 18:15:11 -03 Alexander Dyagilev wrote:
> But why did you do this? Does the supporting of 10.15 really increase
> the development cost for Qt Company?

I can't speak for the Qt Company costs, particularly for the fact that this is
one of their LTS releases.

But in general, it does increase the costs overall. There are new APIs that we
can use if we don't have to keep 10.15 compat, there's one fewer platform to
test on (usually with a virtual machine) before release, and so on. The
benefits may not be realised now, but they will come in the future.

For me specifically, what matters is that 11.0 dropped support for Intel Macs
that don't have AVX2 support, meaning that I can now assume that all machines
running Qt 6.5 natively have 

Re: [Development] [Interest] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Development]

Hi,

This mailing list thread is actually already part of the discussion. I am sure 
the relevant stakeholders will read though the mails. One important thing: the 
question is whether or not the _latest_ Qt version supports 3 or 4 generations 
of macOS – because we already support the older macOS version with the earlier 
Qt releases. We are avoiding to the extent possible dropping supported 
platforms from released versions of Qt, so macOS 10.15 continues to be 
supported with Qt releases up to Qt 6.4 in any case. This also leads into Qt 
supporting such macOS versions that Apple no longer support – like the 
discussed macOS 10.15 that is supported in Qt 6.4, but no longer supported by 
Apple.

Yours,

Tuukka

From: Development  on behalf of coroberti 

Date: Monday, 19. December 2022 at 8.43
To: Qt development mailing list , Qt Interest 

Subject: Re: [Development] [Interest] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

Thank you, Thiago, for your understanding and the assistance proposed.

Thus, we need it to be approved by the Qt Company.

Tukka, can we get the people of the Qt Company sitting and at least discussing:

1. The general issue related to the level of Qt support for Mac platforms
considering four (4) versions to support instead of the current three (3).


2. The concrete case of Mac Support for Qt 6.5.

Even if you come back and say - sorry, we considered, but decided to
turn it down,
still the effort will be very much appreciated.

Thanks in advance for considering the options.

Kind regards,
Robert Iakobashvili

___
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

Re: [Development] [Interest] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Development]

Dropping the interest list to discuss a bit the macOS virtualization.

> you *can* buy server grade Mac systems. They are called Mac Pro and...

Apple's standard license agreement allowes to virtualize two macOS instances on 
macOS. For this level Mac Mini is quite sufficient, better if the next model 
comes with more RAM.

So even if we would take the cost of Mac Pro -level hardware, we would not be 
able to run more than two VMs per each machine.

Anyways, for the moment we don't yet have even that in use, just looking into 
leveraging the new virtualization framework Apple provides. There is also the 
issue of supporting both Intel and ARM processors during the transition period, 
which about doubles the HW need.

Yours,

Tuukka


Lähettäjä: Thiago Macieira 
Lähetetty: sunnuntaina, joulukuuta 18, 2022 3:29 ap.
Vastaanottaja: development@qt-project.org ; 
inter...@qt-project.org 
Kopio: Tuukka Turunen 
Aihe: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

On Saturday, 17 December 2022 05:40:48 -03 Tuukka Turunen via Interest wrote:
> at least between versions 10.15 and 11 there does not seem to be a
> major drop in what HW is supported.

There is a drop, but we're talking about  CPUs launched in 2013 and older.
Specifically, 11.0 drops support for Sandy Bridge and Ivy Bridge Macbooks and
Mac Minis. Whether you count that as "major" or not, I'll leave it up to you.

What matters to me is that those were the last AVX-incapable CPUs, which allow
us to assume that AVX2 is present.

> There is also positive development happening. With the latest versions the
> virtualization support is improving so that we are hopeful to be able to
> use the hardware more efficiently (by running two virtual machines in each
> physical HW). So while macOS is still far from the convenience we have with
> Linux and Windows that support sever grade hardware, things are getting
> better with Macs as well going forward (not for 10.15, though).

I wonder how Apple tests their stuff. All the CIs that run macOS that I know of
as well as cloud providers (AWS in particular) simply have several thousand
Mac Minis.

However, you *can* buy server grade Mac systems. They are called Mac Pro and
they come with up to 28-core Intel Xeon CPUs. They even come in rack form.
But, of course, they cost an arm and a leg (Apple mark-up). The base model
with 8 cores costs as much as a Dell Powerline rack workstation with a 20+
cores of the same Xeon generation. The top of the line model with 28 cores is
roughly the same price as an workstation or full server with two 28-core Xeon
Gold, or servers with two 32-core Xeons of the generation after that with a
slightly lower base clock.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Tuukka Turunen via Development]

Hi,

Most of the macOS users are quite quick to take on new OS versions and this is 
true also for adoption of macOS versions with the new numbering scheme. Apple 
hardware is also rather good in keeping support for new OS versions and at 
least between versions 10.15 and 11 there does not seem to be a major drop in 
what HW is supported.

The challenge we have with supporting macOS versions is that some users migrate 
really quickly, so we need to work a lot with the unreleased (developer beta) 
versions in order to ensure Qt works well with the new macOS version optimally 
before it is even released for production. We also aim to keep supporting older 
versions and the ones in between. This means quite a lot of CI system load – 
especially as we now have both Intel and ARM architectures to test on.

There is also positive development happening. With the latest versions the 
virtualization support is improving so that we are hopeful to be able to use 
the hardware more efficiently (by running two virtual machines in each physical 
HW). So while macOS is still far from the convenience we have with Linux and 
Windows that support sever grade hardware, things are getting better with Macs 
as well going forward (not for 10.15, though).

Related to the usage of 10.15 one indication comes from Creator telemetry. 
Based of this roughly 8% of the macOS users this year have version 10.15. Of 
course, this is not a direct indicator for how many end users of Qt based apps 
there are with macOS 10.15, just how much of the developers using Creator have 
it. Telemetry is fully optional, but I think it is reasonable accurate for this 
type of data point as the OS version is unlikely to greatly affect sending or 
not sending the telemetry data. Note also that we have a lot of different Qt 
versions supporting macOS 10.15, and many applications are still using Qt 5.

Yours,

Tuukka

From: Interest  on behalf of Thiago Macieira 

Date: Saturday, 17. December 2022 at 1.20
To: development@qt-project.org , 
inter...@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops
On Friday, 16 December 2022 18:15:11 -03 Alexander Dyagilev wrote:
> But why did you do this? Does the supporting of 10.15 really increase
> the development cost for Qt Company?

I can't speak for the Qt Company costs, particularly for the fact that this is
one of their LTS releases.

But in general, it does increase the costs overall. There are new APIs that we
can use if we don't have to keep 10.15 compat, there's one fewer platform to
test on (usually with a virtual machine) before release, and so on. The
benefits may not be realised now, but they will come in the future.

For me specifically, what matters is that 11.0 dropped support for Intel Macs
that don't have AVX2 support, meaning that I can now assume that all machines
running Qt 6.5 natively have it. We had further changes based on this
assumption ready to go for 6.5, but they got removed at the last minute due to
unexpected side-effects and the feature freeze being too close.

On Friday, 16 December 2022 19:44:16 -03 Michael Jackson wrote:
> I agree here. Is Qt 6.5 now using an API or a compiler feature that macOS
> 10.15 does not support?

As of *today*, no. This may change tomorrow, as developers continue to do
their work. That means that, as of *today*, Qt 6.5 *could* be compiled to run
on 10.15, by just lowering the default minimum version somewhere in a config
file. But we are not promising that this will remain true and especially we are
not testing that it works.

We had to make a call and following Apple's own support lifetime makes sense.
If you want to stay on an OS that is not receiving important fixes, then you
can also stay on a Qt that is not receiving fixes. Though unlike Apple, you can
backport fixes to 6.4 yourself or remove the new requirements from 6.5 yourself
(or contract someone to do it for you).

Moreover, there's a time delay. This affects Qt 6.5, which will be released in
March 2023, which means it probably affects applications released in May 2023
and later.

>  Is there a security library that Qt 6 depends on (OpenSSL is my guess) that
>  10.15 isn't now updating? Is Qt 6 using the new APIs from that version of
>  OpenSSL (or what ever library broke)? Is there a graphics API that Qt 6
>  now depends on that is macOS 11.0 and greater? Maybe that is the reason?

Any of the above or others may become another reason. The point is that we
need to officially drop the platform first, before we can depend on and require
some of those APIs. It's not the other way around.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



___
Interest mailing list
inter...@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Development mailing list

Re: [Development] Proposal: let's change the release schedules a bit

[Tuukka Turunen via Development]

Hi,

One of the main problems we face every time with the feature freeze is a lot of 
changes coming in just before the deadline. While this is quite natural as 
such, it does also cause some amount of instability and problems in getting the 
full integration test round completed regularly. There are many ways to tackle 
this issue and a lot of things have already been done (such as introducing a 
new freeze point for platforms/configurations in CI before the FF). Having the 
FF date just before a major holiday period is one item that possibly increases 
the instability. Not everyone is on vacation at the same time and especially 
during the summer different countries tend to have a bit different general 
preferences for the primary holiday period. Having the FF in January instead of 
December and August instead of June would likely reduce the number of changes 
coming in just before the deadline. Spreading the changes more evenly in the 
feature development timeline makes it easier to keep integration test rounds 
passing regularly.

Yours,

Tuukka


From: Development  on behalf of Volker 
Hilsheimer via Development 
Date: Thursday, 8. December 2022 at 14.03
To: Jani Heikkinen 
Cc: development@qt-project.org 
Subject: Re: [Development] Proposal: let's change the release schedules a bit
For me, the argument that Eddy makes is very strong: a milestone or deadline 
right after holidays has the potential of ruining those holidays, without 
giving any meaningful extra time to get features done.

Releases of operating systems have some relevance: new macOS and Windows 
versions have in recent cycles happened around March/April and 
October/November. But even if we try to have the Qt release shortly after those 
to claim quick support, in reality it would probably be “technology preview” 
status anyway, knowing how much time it takes to make new CI configurations 
significant. And TP status can just as well be achieved based on beta and 
preview versions. Linux distro cycles are more relevant to align with as we are 
upstream, but in practice I’d expect more practical value in having the first 
or second patch release in a distro. So in summary, I don’t think any of those 
need to have a strong influence on our .0 release timing.

What I don’t quite understand is why a long beta period is a problem. We get 
valuable feedback from community and customers during that, and I vaguely 
remember some reports of regressions coming in pretty late in the process, just 
before or even after the release candidate. I don’t know whether those reports 
came in late because users wait until things look almost ready (i.e. RC 
available), or because it simply takes time before enough users try out a beta. 
In the former case, a longer stabilization cycle makes no difference; in the 
latter case, we should rather make it longer.

Perhaps we have some data on that (how do download figures develop compared to 
tickets in JIRA reported against preview versions), but I haven’t seen anything 
that I’d consider conclusive. And without knowing, I don’t see much value in 
trying to optimize things either way. Eddy’s concern on the other hand is very 
tangible.


Volker





> On 7 Dec 2022, at 12:48, Jani Heikkinen via Development 
>  wrote:
>
> Hi!
>
>> Jani: what is the problem with that calendar interval's present length ?
> We need ~13 weeks (real working time) from the feature freeze to the final 
> release. Currently we have holidays during that period and so on we need to 
> reserve much longer calendar time for that. E.g. with Qt 6.5 this time is 
> planned to be a bit more than 15 weeks and with Qt 6.4 it was a bit more than 
> 16 weeks.
> For me this hasn't been a problem at all but I have heard some other opinions 
> as well; someone wants to finalize new things during holidays and someone 
> isn't that much in holiday e.g Christmas time. For those this would give few 
> weeks extra implementation time between the releases...
>
>>> I would sooner move the schedule half a month earlier - November FF for 
>>> February release, May FF for August release - and accept the calendar 
>>> interval between the two.
> Unfortunately this isn't good option; finalizing the "summer" release would 
> be done during summer holiday season and it won't work. For winter release 
> this could work...
>
> And please note: I am not proposing to move Qt 6.5 FF; It will stay 9.12.2022 
> as planned. But this would be something for Qt 6.6 ->. But like I wrote above 
> this isn't anyway mandatory for me, just a proposal. If most of us prefer the 
> existing frame then let's just continue with that :D
>
> br,
> Jani
>
>> -Original Message-
>> From: Edward Welbourne 
>> Sent: maanantai 5. joulukuuta 2022 17.17
>> To: development@qt-project.org; Jani Heikkinen ;
>> Ivan Solovev 
>> Subject: Re: Proposal: let's change the release schedules a bit
>>
>> Ivan Solovev (5 December 2022 14:42) wrote:
>>> Also, as a developer, I 

Re: [Development] Requesting Feature Freeze exception for CTF tracing backend

[Tuukka Turunen via Development]

Hi,

It would be good to have these in.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Antti 
Määttä via Development  puolesta
Lähetetty: perjantaina, joulukuuta 9, 2022 3:41 ip.
Vastaanottaja: development@qt-project.org 
Aihe: [Development] Requesting Feature Freeze exception for CTF tracing backend

Hi,

Following two changes CTF tracing backend 
(https://bugreports.qt.io/browse/QTBUG-106399, 
https://codereview.qt-project.org/c/qt/qtbase/+/440749) and
related tool for generating tracepoints files 
(https://bugreports.qt.io/browse/QTBUG-107238, 
https://codereview.qt-project.org/c/qt/qtbase/+/436672) were not finished on 
time before feature freeze.

The first change extends the existing Q_TRACE mechanism with a new platform 
independent backend based on CTF format. The second one is a tool that makes it 
easier to generate tracepoint files for the existing tracegen tool.

The changes are required for application level profiling and are the basis for 
further development in that area. It would be beneficial to get those changes 
in for the LTS 6.5 release.

The changes are currently in review and should not have work left in them 
unless something comes up based on new comments.

Regards,
Antti Määttä
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6.2.6 LTS Commercial released

[Tuukka Turunen]

Hi,

You are right that cross-posting release announcements to multiple lists might 
actually not be needed? These three lists (announce, release, development) are 
the ones often used for announcing a new release. It might be that announcing 
only via the announce list would be enough. For a new release there is also 
blog post written and of course many don’t follow any of these channels but 
just see a new item pop up in the online installer.

Yours,

Tuukka

From: Development  on behalf of Konstantin 
Ritt 
Date: Tuesday, 27. September 2022 at 14.31
To: Tarja Sundqvist 
Cc: development@qt-project.org , 
releas...@qt-project.org , annou...@qt-project.org 

Subject: Re: [Development] Qt 6.2.6 LTS Commercial released
Please stop announcing this kind of updates through the development mailing 
list!


Konstantin


вт, 27 сент. 2022 г. в 14:20, Tarja Sundqvist 
mailto:tarja.sundqv...@qt.io>>:
Hi all,

we have released Qt 6.2.6 LTS Commercial today. Please see the blog post:
https://www.qt.io/blog/commercial-lts-qt-6.2.6-released


Big thanks to everyone involved & have nice autumn!



Best regards

Tarja Sundqvist

Release Manager

___
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

Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 6.2 branch(es) on 20th April

[Tuukka Turunen]

Hi Konstantin,

I am sorry to hear that you are unhappy with Qt 6.2 moving to the 
commercial-only long-term-support phase with release of Qt 6.2.5.

We are no holding back on bug fixes, though.

All applicable bug fixes go to dev and are picked to all active branches. The 
fix to QTBUG-102962 was merged to 6.3 branch at the end of April, so the fix is 
in Qt 6.3.1 released in June, as well as in the latest Qt 6.3.2 release as well 
as the soon-to-be released Qt 6.4.0 release.

Yours,

Tuukka


From: Development  on behalf of Konstantin 
Ritt 
Date: Monday, 19. September 2022 at 15.46
To: development@qt-project.org 
Subject: Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 
6.2 branch(es) on 20th April
It is probably the most destructive and annoying thing you did!

I'll try to rephrase what you said in that announcement: "Dear community, 
please stick to unstable, semi-functional versions of Qt, test them and report 
bugs you've found (for free), so we could better support our valuable customers 
(not you). Your contributions are welcomed (but you have to pay some money to 
us to get any gain from your fixes, unless you're ok with sticking to some 
newer semi-functional version of Qt). Thanks for everything you did for Qt 
project (we don't appreciate that). That's how Open Governance works, b???h!"

Am I exaggerating? Let's briefly look at 
https://bugreports.qt.io/browse/QTBUG-102962?jql=project%20%3D%20QTBUG%20AND%20component%20%3D%20Multimedia%20and%20fixVersion%20%3D%206.2.5

Okay, you won: I'll buy your commercial license, just to share your 
commercial-only repositories to everyone!

Regards,
Konstantin


ср, 20 апр. 2022 г. в 10:01, Tarja Sundqvist 
mailto:tarja.sundqv...@qt.io>>:
Hi,

With Qt 6.3.0 released and the first patch release (Qt 6.3.1) coming soon, it 
is time to enter the commercial-only LTS phase for Qt 6.2 LTS. All the existing 
6.2 branches remain publicly visible, but they are closed for new commits and 
cherry-picks. The exception is the Qt WebEngine, which has a 3rd party LGPL 
dependency.

Closing happens today, 20th April 2022. After this, the cherry-picks go to 
another repository that will be available only for the commercial license 
holders. We will arrange repository access to the commercial license holders, 
so in addition to the official releases, it is possible to use the repositories.

The first commercial-only Qt 6.2.5 LTS patch release is planned to be released 
in May.

The external module maintainers that have access to the Qt 5.15 commercial-only 
repositories, will also have access to the Qt 6.2 commercial-only repositories. 
If you notice that you don’t have access even if you should have, please 
contact me (tarja.sundqv...@qt.io) as I am the 
release manager for the commercial-only LTS releases.

Best regards,
Tarja Sundqvist
Release manager
___
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

Re: [Development] Updates on Qt Location

[Tuukka Turunen]

Hi Kevin et al,

Like said in the initial mail: “Development happens in the dev branch, against 
the dev-branches of the rest of Qt.”

So things will work at least to the extent of compilation and passing whatever 
tests are enforced by CI. However, as there is no intention of making an 
official release for Qt 6.3 and Qt 6.4 it is not recommended that distributions 
include this module. Additional testing and feedback is always welcome – it 
will also help this to be something to potentially ship with Qt 6.5.

While the Qt Location is one of the less frequently used modules, it does still 
have a large number of users in absolute terms (due to Qt being so widely 
used). So we certainly want to have this functionality – but some work is 
needed.

Yours,

Tuukka

From: Development  on behalf of Kevin 
Kofler via Development 
Date: Saturday, 23. July 2022 at 15.36
To: development@qt-project.org 
Subject: Re: [Development] Updates on Qt Location
Volker Hilsheimer wrote:
> In the dependency declaration in the current dev branch [1], qtwebengine
> lists qtpositioning, and not qtlocation.
>
> [1] https://code.qt.io/cgit/qt/qtwebengine.git/tree/dependencies.yaml
>
> So I assume that this covers the geolocation functionality that was needed
> from Qt Location in Qt 5. After all, we have been releasing Qt WebEngine
> with Qt 6 for a while now without Qt Location being available.

Understood. So with Qt Positioning being separate, I guess you can do more
experiments with Qt Location now.

Still, if GNU/Linux distributions are to ship it, they will need it building
and running against Qt 6.3 and soon 6.4.

> Once we have the 6.2-based Qt Location in good shape, I will probably not
> be able to keep spending a lot of my time on that module, as there is
> plenty to do elsewhere. I'll come back to Qt Location when Qt 6.5 is
> getting close.
>
> But anyone is of course welcome to see what it takes to make it also work
> with 6.3 and 6.4, and to contribute patches. Updating the 6.3 and 6.4
> branches so that necessary patches can be contributed will of course not
> be a problem. We can build that bridge once we get there.

Well, that leaves the work to keep your code working to distributors. I am
not sure Qt Location will be shipped by anyone before 6.5 if that is its
upstream state (especially now that the positioning parts, which are used by
several other packages, are separate). If that is what you want, fine.

Kevin Kofler

___
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

Re: [Development] Proposal to delete the "Maintainers" group in gerrit

[Tuukka Turunen]

Hi,

We could move the authorative maintainer list to be a QUIP instead of a Wiki 
page.

Yours,

Tuukka

From: Development  on behalf of Volker 
Hilsheimer 
Date: Tuesday, 28. June 2022 at 17.41
To: development@qt-project.org 
Subject: [Development] Proposal to delete the "Maintainers" group in gerrit
Hi,

As per the Governance Model QUIP [1], the authoritative list of maintainers is 
the wiki page [2]

[1] https://quips-qt-io.herokuapp.com/quip-0002.html#maintainers
[2] https://wiki.qt.io/Maintainers

We have a “Maintainers” group in gerrit as well [3], which is not mentioned in 
the QUIP, and which does not control any access or privileges in the context of 
code reviews on gerrit. From what we have seen, the only practical use this 
group ever had was for the recent Chief Maintainer voting.

[3] 
https://codereview.qt-project.org/admin/groups/a60ed457f6e3833c81023c72743ba73c7e23fb09,members

If that is the only or best mechanism we have to control access to such a 
voting system, then I’d rather have us create such a gerrit group from the wiki 
page source when needed, and discard it afterwards so that we continue to have 
only a single source of truth that we need to maintain.

If anyone is aware of any other reason why this group needs to exist, please 
share! Otherwise I will ask the gerrit-admins to delete the group.


Volker

___
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

Re: [Development] Qt 5.15.10 LTS Commercial released

[Tuukka Turunen]

Hi,

The release notes are stored within Qt Account (under Downloads, select 
Product: Qt and Version: 5.15.10), i.e. one needs to have a commercial license 
to see those.

Yours,

Tuukka

From: Development  on behalf of Milian 
Wolff via Development 
Date: Wednesday, 8. June 2022 at 0.53
To: development@qt-project.org 
Subject: Re: [Development] Qt 5.15.10 LTS Commercial released
On Dienstag, 7. Juni 2022 18:03:31 CEST Tarja Sundqvist wrote:
> Hi all,
>
> we have released Qt 5.15.10 LTS Commercial today. Please see the blog post:
> https://www.qt.io/blog/commercial-lts-qt-5.15.10-released

Hey there,

where are the "release notes" to be found which contain the "list of fixes and
the overview of all important changes"?

Please, can you add that directly to the release announcement in the future?

Thanks

--
Milian Wolff | milian.wo...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainance Tool

[Tuukka Turunen]

Great to hear. Thanks for reporting the issue and verifying that authentication 
works now.

In case someone is curious what the bug was: the login form did not disable the 
authentication button after it was pressed, so it was possible that multiple 
requests were sent to backend, which then caused the failed authentication.

Yours,

Tuukka

From: Development  on behalf of Konstantin 
Ritt 
Date: Wednesday, 9. March 2022 at 7.56
To: Alexander Akulich 
Cc: Qt development mailing list 
Subject: Re: [Development] Maintainance Tool
The bug is fixed now.


Regards,
Konstantin


вс, 6 мар. 2022 г. в 16:18, Konstantin Ritt 
mailto:ritt...@gmail.com>>:
Volker:

On Fri, Mar 4, 2022 at 8:56 PM Konstantin Ritt 
mailto:ritt...@gmail.com>> wrote:
Oh well, my codereview.qt-project.org account 
is also inaccessible. This is not about your attitude towards RU gov, but your 
attitude towards me personally.

[cid:ii_l0corabk0]

Sure I can use Tor to log-in from some other IP. But I wouldn't, that's your 
fault not mine.

P.S. Do I have a moral right to put my -2 to contributions not due to the code 
quality but due to their author's mother language, country or nationality. Do 
*you* have a moral right to hit my rights due to my mother language, country or 
nationality?

Konstantin

It could be a simple bug introduced in haste. Tuukka said they'll check what 
causes this.


Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainance Tool

[Tuukka Turunen]

Hi Konrad et al,

Like already mentioned Qt Project systems, code.qt.io repositories, github 
mirror etc are not blocked. Online installer for open-source users is blocked 
from Russia and Belarus based IP addresses. Plan is to block also 
download.qt.io and possibly some of the qt.io websites. These are done based on 
IP address.

Blocking the installer and access to binaries affects a much larger number of 
users than those who are active in the community. It impacts also many who 
create closed source products using the open-source Qt.

Yours,

Tuukka

From: Development  on behalf of Konrad 
Rosenbaum 
Date: Friday, 4. March 2022 at 23.25
To: development@qt-project.org 
Subject: Re: [Development] Maintainance Tool

Hi Tuukka,

I believe an official statement from the Qt Company is in order - right now 
people are forced to find out the hard way whether they are blocked and how far 
the block goes. It is impossible to tell whether it is on purpose or not and 
what the purpose would be.

It does not matter what side people are on, they deserve to know what's 
happening to them.

It's also easier to accept and support this, if we know what "this" is.



Please state very clearly:

Who is being blocked? (Location, commercial customers, open source users, 
developers, ...?)

Why are they blocked and for how long? (We might even agree with your 
reasoning.)

What services are supposed to be blocked and which ones are not supposed to be 
blocked? (Commercial vs. Open Source, Binary vs. Source Downloads, Users vs. 
Contributors, ...)

Where to report bugs in this block? (e.g. is Konstantin really supposed to be 
blocked from contributing?)

And what discussions will be redirected to /dev/null?



Right now we live in a situation that we all had hoped would not occur again in 
Europe. We had hoped that the hard learned lessons of our grand parents would 
prevent this from happening. Let's at least try to be a voice of reason in this 
situation.



Konrad


On 04/03/2022 17:34, Tuukka Turunen wrote:
Hi,

Like already mentioned, use of the online installer is blocked from certain IP 
addresses.

Access to the Qt Project source code repository has not been blocked.

If you wish to discuss this, please remember 
http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html

Yours,

Tuukka

From: Development 
<mailto:development-boun...@qt-project.org> 
on behalf of Konstantin Ritt <mailto:ritt...@gmail.com>
Date: Friday, 4. March 2022 at 18.23
To: Denis Shienkov <mailto:denis.shien...@gmail.com>
Cc: Qt development mailing list 
<mailto:development@qt-project.org>
Subject: Re: [Development] Maintainance Tool
Plz restrain your emotions. There is no reason to spread hysteria even more.

Konstantin


пт, 4 мар. 2022 г. в 19:09, Denis Shienkov 
mailto:denis.shien...@gmail.com>>:

Yes, it's kind of hysterical. I don't understand what the Qt company wants to 
achieve in the end? What is the purpose?

So far, it looks more like a clowning: "the circus is gone, but the clowns 
remain."

Qt Company can't stick your tongue out of the USA ass? :)

I had a higher opinion of Qt Company up to this point ...

This is not serious somehow, some kind of kindergarten. LOL. :)

BR, Denis


04.03.2022 18:58, Konstantin Ritt пишет:
As long as I can fetch sources I wouldn't take any actions.
But anyways, bringing your own political preferences to the open source world 
rules is a quite hypocritical move.
In the adult world, it doesn't matter if your community members / contributors 
have a skin tone, political or sexual preferences not like yours, or an IP 
address that belongs to some particular territory.

Disappointed Konstantin


пт, 4 мар. 2022 г. в 18:01, Andy Shaw mailto:andy.s...@qt.io>>:
Hi,

It is because your IP is detected to be in a country we do not allow downloads. 
If you are not able to access something you have purchased then let me know and 
I will get someone to get in touch with you directly about this. Otherwise, for 
the time being, this IP block will be in place.

Regards,
Andy

From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of Konstantin Ritt
Sent: Friday, March 4, 2022 1:43 PM
To: Konstantin Shegunov mailto:kshegu...@gmail.com>>
Cc: Qt development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] Maintainance Tool

I don't care. I need some explanations here, at public dev ML.

Regards,
Konstantin


пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov 
mailto:kshegu...@gmail.com>>:
Hi,
I imagine you're using a russian IP address, so this[1] should shed some light 
on the matter.

Kind regards,
Konstantin.

[1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia




___

Development mailing list

Development@qt-project.org<mailto:Development@qt-project.org>

https://lists.qt-project.org/listinf

Re: [Development] Maintainance Tool

[Tuukka Turunen]

Hi,

Like already mentioned, use of the online installer is blocked from certain IP 
addresses.

Access to the Qt Project source code repository has not been blocked.

If you wish to discuss this, please remember 
http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html

Yours,

Tuukka

From: Development  on behalf of Konstantin 
Ritt 
Date: Friday, 4. March 2022 at 18.23
To: Denis Shienkov 
Cc: Qt development mailing list 
Subject: Re: [Development] Maintainance Tool
Plz restrain your emotions. There is no reason to spread hysteria even more.

Konstantin


пт, 4 мар. 2022 г. в 19:09, Denis Shienkov 
mailto:denis.shien...@gmail.com>>:

Yes, it's kind of hysterical. I don't understand what the Qt company wants to 
achieve in the end? What is the purpose?

So far, it looks more like a clowning: "the circus is gone, but the clowns 
remain."

Qt Company can't stick your tongue out of the USA ass? :)

I had a higher opinion of Qt Company up to this point ...

This is not serious somehow, some kind of kindergarten. LOL. :)

BR, Denis


04.03.2022 18:58, Konstantin Ritt пишет:
As long as I can fetch sources I wouldn't take any actions.
But anyways, bringing your own political preferences to the open source world 
rules is a quite hypocritical move.
In the adult world, it doesn't matter if your community members / contributors 
have a skin tone, political or sexual preferences not like yours, or an IP 
address that belongs to some particular territory.

Disappointed Konstantin


пт, 4 мар. 2022 г. в 18:01, Andy Shaw mailto:andy.s...@qt.io>>:
Hi,

It is because your IP is detected to be in a country we do not allow downloads. 
If you are not able to access something you have purchased then let me know and 
I will get someone to get in touch with you directly about this. Otherwise, for 
the time being, this IP block will be in place.

Regards,
Andy

From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of Konstantin Ritt
Sent: Friday, March 4, 2022 1:43 PM
To: Konstantin Shegunov mailto:kshegu...@gmail.com>>
Cc: Qt development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] Maintainance Tool

I don't care. I need some explanations here, at public dev ML.

Regards,
Konstantin


пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov 
mailto:kshegu...@gmail.com>>:
Hi,
I imagine you're using a russian IP address, so this[1] should shed some light 
on the matter.

Kind regards,
Konstantin.

[1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia



___

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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6.2.0 RC released

[Tuukka Turunen]

Hi,

We have gotten a lot of valuable feedback on the Qt 6.2 pre-releases and the RC 
looks very solid. There are always some things to fix, and now it is crucially 
important to get all feedback quickly to the release team.

There is time to fix issues before the Qt 6.2.0 final, but that requires that 
the work is done soon. So please take a look into the RC and provide feedback 
as soon as possible.

We have quite a lot of dependencies for the Qt 6.2 release so after a fix is 
done, we do need a few days at least to make all the packages. There are also 
some marketing activities coming with Qt 6.2, so it is important to get it out 
the week after next as planned.

We will also make regular patch releases and there are already some fixes in 
the 6.2 branch targeted to Qt 6.2.1. So in case the issue is not mandatory to 
fix immediately, target fixes to the next patch release. The low-risk issues 
like documentation and examples, we can more easily take into Qt 6.2.0 – as 
long as these are done early enough.

Yours,

Tuukka

From: Releasing  on behalf of Jani Heikkinen 

Date: Thursday, 16. September 2021 at 14.37
To: annou...@qt-project.org , 
development@qt-project.org , 
releas...@qt-project.org 
Subject: [Releasing] Qt 6.2.0 RC released
Hi Everyone!

We have released Qt 6.2.0 RC today. As earlier you can get it via the online 
installer. Src packages are also available in the Qt Account and 
download.qt.io. Delta to the beta4 attached.

The target is to release Qt 6.2.0 at the end of September so please inform us 
immediately if you find some issue that has to be fixed before the official Qt 
6.2.0 release. And please make sure all blockers are also visible in the 
release blocker list: https://bugreports.qt.io/issues/?filter=23304

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Tuukka Turunen]

Hi,

Let’s look into what kind of additional systems we could arrange that helps 
development of Qbs. Just now everyone is busy getting Qt 6.2 and QDS 2.2 
successfully released, but we should be able to look into this latest in the 
beginning of October.

Yours,

Tuukka

From: Development  on behalf of Denis 
Shienkov 
Date: Wednesday, 15. September 2021 at 13.59
To: development@qt-project.org 
Subject: Re: [Development] Qbs development

Hi Lars, Tuukka,

> I also would very much like you to stay here.

AFAIK, a main issue here not about of maintenance behaviour. A main issue in 
the access right on the Qbs project. F.e. right now it is hard to maintenance 
the CI integration with the GitHub, to generate the pre-compiled releases and 
other stuff (maybe Ivan can explain a betetr).

Also, a main issue is for the CI for the bare-metal toolchains, where we need 
to use the self-runners instead of Docker containers (there are impossible to 
use the dockers).

So, if you want to be Qbs stayed in the QtCompany infrastructure, then you need 
to help us a bit, e.g. provide some separate server resources (e.g. two VMs 
with Linux && Windows OS installed) where we can setup all required stuff to 
work with CI. ;)

Because right now I use own host PC as self-runner for CI, what is very bad and 
non-stable approach.  ;)

BR, Denis
15.09.2021 13:32, Lars Knoll пишет:
Hi Ivan,

I also would very much like you to stay here. QBS is great project and 
something that came out of the Qt work and still has very strong ties to it.

I am fully with Tuukka that what we want is to make it a good experience and 
easy for people to work here in the project. Blocking other peoples work is 
certainly not in line with this.

The governance model has the ’no confidence’ clause for a reason and if you 
have tried other means before, I can and will of course arrange such a vote.

Cheers,
Lars



On 15 Sep 2021, at 12:18, Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Hi,

I would not like Qbs development to move away from the Qt project. It is very 
unfortunate that you have had bad experience and misbehavior from one approver. 
We want to constantly improve the experience of working within the Qt project 
and naturally this kind of incidents are not doing that. Therefore, it is very 
good that you have raised the topic in the mailing list, as many were not aware 
of it earlier. On the positive side, I do not think there is any general 
hostility towards Qbs within the Qt projects – on the contrary I can see a lot 
of good co-operation.

Yours,

Tuukka


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Иван Комиссаров mailto:abba...@gmail.com>>
Date: Tuesday, 14. September 2021 at 20.49
To: Lars Knoll mailto:lars.kn...@qt.io>>
Cc: Qt development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] Qbs development
Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt Governance Model 
by moving to GitHub. I have raised this topic on our Discord server and the 
community overall seems positive - there were several votes for the migration 
and no votes against. This migration might be healthy to Qbs as a lot of 
newcomers are not familiar with Gerrit but familiar with GitHub and it’s 
pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs and to the 
rest of Qt world.
If there are no objections, I will create an INFRA issue about the migration - 
it should not be very hard to do.

Ivan



14 сент. 2021 г., в 17:33, Lars Knoll 
mailto:lars.kn...@qt.io>> написал(а):
 Hi,

Let’s also take up the formal part of the request.



On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
Also, some actions might be taken to prevent from happening in the future - if 
technically possible, I’d like to request the revoke of his approver rights on 
the Qbs project as per this part of the Qt Governance Model:
«In extreme circumstances Approver privileges can be revoked by a vote of no 
confidence, proposed by an existing Approver or Maintainer and arranged by the 
Chief Maintainer. Privilege revocation requires a two-thirds majority vote of 
those Approvers and Maintainers who express an opinion.» [3]




On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

This is a relevant question for the Qt project. Any person with approver
rights has the ability to cause a production stop. Ivan is asking for help
in this particular case and I am seconding his request.



Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.



We will also need to consider that the Qt Go

Re: [Development] Qbs development

[Tuukka Turunen]

Hi,

I would not like Qbs development to move away from the Qt project. It is very 
unfortunate that you have had bad experience and misbehavior from one approver. 
We want to constantly improve the experience of working within the Qt project 
and naturally this kind of incidents are not doing that. Therefore, it is very 
good that you have raised the topic in the mailing list, as many were not aware 
of it earlier. On the positive side, I do not think there is any general 
hostility towards Qbs within the Qt projects – on the contrary I can see a lot 
of good co-operation.

Yours,

Tuukka


From: Development  on behalf of Иван 
Комиссаров 
Date: Tuesday, 14. September 2021 at 20.49
To: Lars Knoll 
Cc: Qt development mailing list 
Subject: Re: [Development] Qbs development
Thanks for the response.
I can provide a third option - we can move Qbs out of the Qt Governance Model 
by moving to GitHub. I have raised this topic on our Discord server and the 
community overall seems positive - there were several votes for the migration 
and no votes against. This migration might be healthy to Qbs as a lot of 
newcomers are not familiar with Gerrit but familiar with GitHub and it’s 
pull-request model.
Also, it will clearly separate who can approve/reject patches to Qbs and to the 
rest of Qt world.
If there are no objections, I will create an INFRA issue about the migration - 
it should not be very hard to do.

Ivan


14 сент. 2021 г., в 17:33, Lars Knoll  написал(а):
 Hi,

Let’s also take up the formal part of the request.


On 13 Sep 2021, at 22:59, Иван Комиссаров 
mailto:abba...@gmail.com>> wrote:
Also, some actions might be taken to prevent from happening in the future - if 
technically possible, I’d like to request the revoke of his approver rights on 
the Qbs project as per this part of the Qt Governance Model:
«In extreme circumstances Approver privileges can be revoked by a vote of no 
confidence, proposed by an existing Approver or Maintainer and arranged by the 
Chief Maintainer. Privilege revocation requires a two-thirds majority vote of 
those Approvers and Maintainers who express an opinion.» [3]



On 14 Sep 2021, at 12:34, Richard Weickelt 
mailto:rich...@weickelt.de>> wrote:
The question is whether this is an abuse of approver rights.

This is a relevant question for the Qt project. Any person with approver
rights has the ability to cause a production stop. Ivan is asking for help
in this particular case and I am seconding his request.


Ivan and Richard, do I understand you correctly that you’d like to have a 
formal vote of no confidence according to QUIP-2? Please understand that this 
clause is meant as a last resort, when other solutions have failed.


We will also need to consider that the Qt Governance Model only defines global 
Approver rights for all of the Qt Project. The request was however limited to 
QBS, so we would need to find a way to handle this. I can only see two options 
there, either we start extending our governance model here (can be done with a 
lazy consensus on that extension), or change the scope to the whole project 
having much more severe implications.




Ossi, I (and probably others on this mailing list) would also like to hear your 
view on this. As I stated in my previous mail in this thread, I strongly 
believe, that the people doing the actual work decide on the direction and 
individual changes. The Governance model states the same, the maintainer takes 
the decision in case no agreement can be reached. As far as I can see, your 
actions are conflicting with this.


Thank you,
Lars


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

[Tuukka Turunen]

Hi,

Not taking a stand to this particular issue, we in general are sometimes not 
very good in taking incremental steps. If some review becomes very long, taking 
months to complete, it rarely is the best way to tackle the issue. It can be 
better to split to multiple smaller items and progress those separately (noting 
that sometimes it is not possible). In some cases it would be better to first 
merge a partial solution that improves from current state – and then take one 
or more additional steps to reach the end goal.

Yours,

Tuukka

From: Иван Комиссаров 
Date: Monday, 13. September 2021 at 23.59
To: Qt development mailing list 
Cc: Lars Knoll , Tuukka Turunen , 
Oswald Buddenhagen , Christian Kandeler 

Subject: Qbs development
Hello everybody

I would like to raise an issue about Oswald Buddenhagen abusing his maintainer 
rights. He is constantly blocking the merge of the patchset which implements a 
new feature in Qbs [0]. I started working on this almost a year ago and the 
issue was approved for the first time in October 2020 (!). Since then, Oswald 
popped up more and more random topics, demanding answers to all possible 
questions about the overall architecture and blocking the merge. While I highly 
appreciate his input, I don’t think it’s productive to postpone a relatively 
small feature for almost a year based on the assumption that it may not fit in 
the overall architecture. I prefer to move forward in small step, collect 
use-cases from actual users’ needs and see how this feature shows itself.
Also, Oswald mainly reviews the documentation and makes assumptions about the 
code based onion the documentation… I find this approach flawed, since 
documentation does not (and should not) show the user all the complexity of the 
actual implementation. Another annoying part is that Oswald neither does not 
know the Qbs code nor has desire to read and understand parts he’s commenting 
on.
I’ve been tolerating such behaviour for almost a year, but now I am confident 
that we can and should proceed with the current implementation and that Oswald 
is stalling the Qbs development. We’re not moving forward, I cannot fix bugs 
that depend on this feature I cannot implement new features based on this one - 
see the list of issue blocked by the related JIRA task - [1].

Oswald has been doing this in the past [2] - instead of allowing to contribute 
a small fix for a simple bug, Oswald turned the patchset into a lengthy 
discussion about architecture… I haven’t seen any contributions from Christian 
Gagneraud ever since (might be unrelated, though) and the bug is not fixed as 
of today.
I kindly asked Oswald to remove his -2 and allow me to proceed, but he chose to 
ignore my request. I’d like to ask Gerrit Administrators to remove his -2 so I 
can proceed with the development.

Also, some actions might be taken to prevent from happening in the future - if 
technically possible, I’d like to request the revoke of his approver rights on 
the Qbs project as per this part of the Qt Governance Model:
«In extreme circumstances Approver privileges can be revoked by a vote of no 
confidence, proposed by an existing Approver or Maintainer and arranged by the 
Chief Maintainer. Privilege revocation requires a two-thirds majority vote of 
those Approvers and Maintainers who express an opinion.» [3]

Ivan.

[0] https://codereview.qt-project.org/c/qbs/qbs/+/315910
[1] https://bugreports.qt.io/projects/QBS/issues/QBS-1604
[2] https://codereview.qt-project.org/c/qbs/qbs/+/301461
[3] https://wiki.qt.io/The_Qt_Governance_Model
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] API Change Review for 6.2

[Tuukka Turunen]

Hi,

We have gotten review of the modules with larger number of changes progressing 
well, but a few modules are still without comments.

With the Alpha out and Beta 1 soon ready to be released it is time to complete 
the API review so that we have the agreement upon what to do before release of 
Qt 6.2.0.

Yours,

Tuukka

From: Development  on behalf of David 
Skoland 
Date: Tuesday, 22. June 2021 at 12.48
To: development@qt-project.org 
Subject: [Development] API Change Review for 6.2
Hello everyone!

In accordance to QUIP-10 
(http://quips-qt-io.herokuapp.com/quip-0010-API-review.html), it is again time 
for a review of the changes to the public API from 5.15 and 6.1 to 6.2. As you 
may know, a fair number of modules were reintroduced in 6.2 from 5.15 and were 
adjusted quite a bit. One notable omission from the review round is 
qtmultimedia, which was thoroughly reworked and hence subject to a separate 
review process (ref. Lars).

Relevant Jira: https://bugreports.qt.io/browse/QTBUG-94407
Changes: 
https://codereview.qt-project.org/q/topic:%22api-change-review-6.2%22+(status:open%20OR%20status:abandoned)
All modules in 6.2: https://wiki.qt.io/Qt_6.2.0_Modules

The most important changes are as usual qtbase and qtdeclarative.

Do also note the 6.2 release plan, as this should be completed in a timely 
manner: https://wiki.qt.io/Qt_6.2_Release

A fair number of modules had no interesting changes from 6.1, so they have no 
Gerrit change at all. If you have any questions about any of the changes, let 
me know.

Cheers,

David Skoland

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Tuukka Turunen]

Hi,

Having the controls within declarative and also using the controls more in all 
the relevant examples would be beneficial for the users. So I think this might 
be one dependency we could add, not only for testing.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Volker 
Hilsheimer  puolesta
Lähetetty: perjantaina, kesäkuuta 4, 2021 5:55 ip.
Vastaanottaja: Mitch Curtis
Kopio: development@qt-project.org
Aihe: Re: [Development] Solutions for ensuring that changes in upstream modules 
are tested with downstream modules before merging

> On 4 Jun 2021, at 16:10, Mitch Curtis  wrote:
>
>> -Original Message-
>> From: Volker Hilsheimer 
>> Sent: Friday, 4 June 2021 2:45 PM
>> To: Mitch Curtis 
>> Cc: development@qt-project.org
>> Subject: Re: [Development] Solutions for ensuring that changes in upstream
>> modules are tested with downstream modules before merging
>>
>>> On 4 Jun 2021, at 13:56, Mitch Curtis  wrote:
>>>
>>> Hi.
>>>
>>> A common problem I see is that a change in say qtbase or qtdeclarative can
>> cause test failures in modules that depend on them after that change is
>> merged. As a result, dependency updates for the downstream modules can
>> be blocked, requiring the module maintainer to look into the failure, only to
>> discover that it is caused by an upstream module. This causes a lot of time
>> and effort to be diverted away from regular work. Both upstream and
>> downstream developers would benefit from having more immediate CI
>> feedback on these kinds of changes.
>>>
>>> https://bugreports.qt.io/browse/QTBUG-79454 was created to track this
>> problem. So far the ideas suggested have been:
>>>
>>> - Run tests of dependent modules when testing a change, in addition to
>> the regular tests for that module
>>> - Merge repositories of more tightly coupled modules (e.g. move
>> qtquickcontrols2 into qtdeclarative)
>>>
>>> It would be beneficial to discuss the advantages and disadvantages of
>> these and other solutions so that we can address this problem.
>>>
>>> Cheers.
>>
>>
>> Excellent topic for the upcoming Qt Contributors Summit, Mitch, great if you
>> can add it to the list of topics:
>>
>> https://wiki.qt.io/Qt_Contributors_Summit_2021_-_Program
>>
>> Which doesn’t mean that we shouldn't start the discussion on the list, and
>> maybe we can then conclude it at the summit.
>>
>>
>> Cheers,
>> Volker
>
> OK, added it to the list.
>

Thanks.


As for the topic:

I do think that we have cases where too many modules are lumped into a single 
repo, and cases where we have too much granularity.

For the former: I see no immediate reason why QtNetwork needs to be in qtbase 
(network tests failing is a major cause of unrelated integrations failing), or 
why the Qt Positioning module needs to be in qtlocation.

For the latter: Qt Quick Controls 2 might be better off sharing a commit 
history with QtQuick

However, while we can make adjustments, I also think that there’s no perfect 
solution. It’s always a tradeoff between speed and autonomy on the one, and 
integrity across dependencies on the other hand.


Running more tests is a similar tradeoff, and I don’t think blocking an 
integration into e.g. qtbase because it breaks a leaf module is a good solution 
to the problem. We should aim for fast feedback, and short meantime to recover 
such breakages, and making CI runs take even longer helps with neither. In 
particular if we then can’t make any such changes even though a follow up 
change in a leaf module is already available and just needs to wait for the 
dependency update. Then we are in a deadlock, unless we keep the code in qtbase 
working for both versions of e.g. qtdeclarative, which is not always practical.


The problem is perhaps not that we break things, but that we don’t notice for 
too long that we broke things? And once we do notice, we often seem to be 
unwilling to revert the change that did cause the breakage, if things don’t get 
fixed quickly.


To know about breakage quicker, a nighly run of all tests against “HEAD of 
everything” could help. Our dependency updates give us some of that, and we 
usually respond swiftly when an update fails. It shouldn’t be on the leaf 
module maintainer alone to follow up on things, and I do have the impression 
that people do take ownership, at least once they see that their base module 
change broke stuff. I’m sure we can improve there as well.
But now that Qt 6 is out, I’d expect that a “everything at HEAD” toplevel build 
should work most of the time. My local worktrees are usually at HEAD of 
everything, and it’s rare that there are build problems at least.


Lastly, I do think that we could do more in encoding assumptions made across 
modules in unit tests. If a change in qtdeclarative breaks an assumption made 
in qqc2, then ideally there’s a unit test in qtdeclarative that would fail. We 
use private APIs a lot across some modules, but we don’t have unit tests for 
them in the base 

Re: [Development] Changes to Freenode's IRC

[Tuukka Turunen]

Hi,

Before simply voting for new irc provider, I would still prefer to have the 
QtCS discussion on the topic.

We should also discuss and define what is the intention / intentions of the 
channels, because this can affect the choice.

If it is for contributors to discuss with each other and release team meetings 
it may be different than if intention is to discuss with Qt users. For the 
latter purposes we should have a bit wider discussion and also plan how to best 
link this to the needs of today. For the former we should also consider how to 
attract new contributors, not only think what works best for existing. That 
being important as well.

Another important thing to note is that everyone developing Qt is now pretty 
much focused in completing thing for Qt 6.2 FF. So now is not the best time to 
plan how to develop the communication channels.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Giuseppe 
D'Angelo via Development  puolesta
Lähetetty: perjantaina, toukokuuta 21, 2021 7:07 ip.
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Changes to Freenode's IRC

On 21/05/2021 14:40, Cristián Maureira-Fredes wrote:
> @Giuseppe regarding the consensus, should we do a thread for voting
> the movement to libera only? or you think we could agree differently
> of doing the move.

Yes, I'm afraid that I screwed this one up, apologies :(

I'll guess I'll start a new thread, *only* for voting.

Thank you,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Freenode's IRC

[Tuukka Turunen]

Hi,

One option (following a bit what Andy wrote below) would be to do nothing 
immediately, but instead discuss this in the upcoming Qt Contributor’s Summit 
to plan the next steps.

While there is currently a lot of turmoil around freenode they have not 
disappeared or intend to do so (https://freenode.net/news/freenode-is-foss) and 
we should consider multiple sides of the view before making the decision on 
communication platform.

Yours,

Tuukka

From: Development  on behalf of Andy 
Nichols 
Date: Thursday, 20. May 2021 at 17.12
To: Giuseppe D'Angelo 
Cc: development@qt-project.org 
Subject: Re: [Development] Changes to Freenode's IRC
> Anyways: this isn't the topic of this thread. The topic of this thread is 
> what to do with the currently officially endorsed IRC channels on Freenode.

Sure it is.  My vote is to do nothing (stay on Freenode), and let our IRC 
presence continue its fade into obscurity.

Then replace it with something better as the officially endorsed community chat.

Regards,
Andy Nichols
___
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

Re: [Development] Changes to Freenode's IRC

[Tuukka Turunen]

Hi Jason,

You can check the planned modules for Qt 6.2 from: 
https://www.qt.io/blog/qt-roadmap-for-2021

The first snapshot of Qt 6.2 does not yet contain all of those, but then again 
we are still some weeks (2.5) away from FF.

It is ok to discuss this type of matters in the mailing list, but it is not 
constructive to use it in order to derail other discussions. Like this one 
being about what to do with the IRC situation at hand.

While many are still somewhat tuned in on the IRC channel it is clear that the 
traffic is very modest. It may be that having another system would work better, 
or perhaps the mailing lists and other available channels are adequate for the 
need.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Jason H 
 puolesta
Lähetetty: keskiviikkona, toukokuuta 19, 2021 11:16 ip.
Vastaanottaja: Kai Köhne
Kopio: development@qt-project.org
Aihe: Re: [Development] Changes to Freenode's IRC


> Can we agree to keep the bashing out of this channel?

You raise important questions. First, what is "bashing", and where is it 
appropriate? Or, as I see my behavior, where is being critical of Digia 
appropriate?

As a long-time Qt user (first commercial license was for 3.3.3) I've seen it go 
through many phases. Nokia LGPL Qt was so great, but I've watched erosion of 
that openness. I formulate my opinions based on ecosystems that I participate 
in, like Arduino, React, Node, etc. I see IMHO criticism of Digia is on the 
rise (https://www.qt.io/blog/commercial-lts-qt-5.15.3-released). I also get a 
lot of emails privately in agreement with my criticisms. So where is the proper 
feedback channel?

I think the situation is exacerbated because of the confluence of two decisions 
on how the Qt 5.15/Qt 6 transition:
1. Qt 6 does not contain all the modules Qt 5.15 did.
2. Qt 5.15 was a LTS, but the releases after 5.15.2 are commercial only.

If Qt 6 had contained all the modules that 5.15 did, OpenSource users would be 
able to switch to 6.
>From https://doc.qt.io/qt-6/whatsnew60.html#removed-modules-in-qt-6-0 the 
>following modules are not in Qt6:
Qt Android Extras   androidextras
Qt Bluetoothbluetooth
Qt Charts   charts
Qt Data Visualization   datavisualization
Qt Graphical Effectsonly QML types
Qt Location location
Qt Mac Extras   macextras
Qt Multimedia   multimedia
Qt Multimedia Widgets   multimediawidgets
Qt NFC  nfc
Qt Positioning  positioning
Qt Purchasing   purchasing
Qt Remote Objects   remoteobjects
Qt Script   qtscript
Qt SCXMLscxml
Qt Script Tools scripttools
Qt Sensors  sensors
Qt Serial Bus   serialbus
Qt Serial Port  serialport
Qt Speech   texttospeech
Qt WebChannel   webchannel
Qt WebEnginewebenginecore
Qt WebSockets   websockets
Qt WebView  webview
Qt Windows Extras   winextras
Qt X11 Extras   x11extras
Qt XML Patterns xmlpatterns

Qt 6.1 then adds back (though some modules got rolled into other modules):
Qt Charts
Qt DataVis
Qt Lottie
Qt SCXML and StateMachine
Qt VirtualKeyboard

This leaves open source users of the Qt6 missing modules in a bind. I decline 
to attribute this to malice, but one way to fix the situation is to provide the 
5.15 non-commercial updates until Qt6 is complete (6.2? allegedly includes 
Serial and WebSockets, but plenty aren't yet included, also: 
https://lists.qt-project.org/pipermail/development/2020-November/040704.html) 
and then just have Qt 6 LTS as commercial only.  I had also thought that the 
5.15 LTS was only going to be limited by commerical-only offline packages, that 
online 5.15 LTS would still be fine.

I would even be fine with there being only one LTS as opposed to how it is done 
now with multiple overlapping LTSs. (Currently 5.12 and 5.15 are LTS)

I don't know how to square Digia's behavior with Qt's Open Governance model 
(https://wiki.qt.io/Qt_Project_Open_Governance) ? I'm trying to where in the 
open source/governance stuff it was decided that making LTS commercial only was 
1) approved by the Open Governance Model 2) exhibits the principals talked 
about in the Open Governance Model.

Let me be clear: I still think Qt (the library) is really great amazing stuff 
and want to thank every single contributor for it. But this shenanigans with 
the licensing is well, shenanigans. Show me another "open source" project that 
goes commerical-only in the LTS branch? The criticism is warranted. By that 
alone, not to mention having a not-yet-viable-next-version.










___
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

Re: [Development] Commercial LTS Qt 5.15.4 released

[Tuukka Turunen]

Hi,

Most of the maintainers are also addressing issues in the commercial LTS 
releases, including also some who do not work for The Qt Company. So in that 
sense it is not completely off, but I do agree that announcing the commercial 
LTS releases via the announce list is probably enough.

Yours,

Tuukka

From: Development  on behalf of Konstantin 
Ritt 
Date: Wednesday, 12. May 2021 at 15.44
To:
Cc: development@qt-project.org 
Subject: Re: [Development] Commercial LTS Qt 5.15.4 released
Wrong list? AFAIK, this mailing list is about developing Qt, not about 
promoting some closed-source products ;p

Regards,
Konstantin


ср, 12 мая 2021 г. в 15:05, Tarja Sundqvist 
mailto:tarja.sundqv...@qt.io>>:
Hi all,


We have released Commercial LTS Qt 5.15.4 today! Please read more information 
from the release blog post: 
https://www.qt.io/blog/commercial-lts-qt-5.15.4-released



Big thanks for everyone involved!



Best regards

Tarja Sundqvist

Release Manager
___
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

Re: [Development] Qt 6.2 Feature Freeze is getting closer...

[Tuukka Turunen]

Hi,

One item to note related to feature freeze of Qt 6.2 is that due to the holiday 
season between FF and final we can’t have exceptions as was done e.g. for Qt 
6.0 FF. So if you are working on some items that are likely to go over the FF 
or cut tight, these should be discussed beforehand.

Note also that there will be a lot of traffic in CI close to the FF time, so 
the more items that can be merged well before, the better.

Yours,

Tuukka

From: Releasing  on behalf of Jani Heikkinen 

Date: Wednesday, 12. May 2021 at 9.31
To: development@qt-project.org , 
releas...@qt-project.org 
Subject: [Releasing] Qt 6.2 Feature Freeze is getting closer...
Hi all,

Just a kindly reminder: Qt 6.2.0 Feature Freeze will be in effect 4th June 2021 
so there is less than a month left for implementing new features, modules etc 
for Qt 6.2

It is time to start listing new features in the release so please start 
updating Qt 6.2 new features page here: 
https://wiki.qt.io/New_Features_in_Qt_6.2

br,
Jani Heikkinen
Release Manager

From: Jani Heikkinen
Sent: Tuesday, April 13, 2021 11:50 AM
To: development@qt-project.org; releas...@qt-project.org
Subject: Qt 6.2 initial schedule & FF preparations

Hi All,

Even Qt 6.1 RC isn't out yet it is time to start preparations for Qt 6.2 as 
well.

Initial Qt 6.2 schedule (which is already visible in 
https://wiki.qt.io/Qt_6.2_Release):
- Feature Freeze 4th June 2021
- Alpha release 15th June 2021
- Beta1 release 6th July 2021
- RC 14th September 2021
- Final release 28th September 2021

Schedule is based on Lars's timeline announcement: 
https://lists.qt-project.org/pipermail/development/2020-November/040704.html

So there isn't anymore that much time to implement new features and modules for 
Qt 6.2. Please inform me all new module as soon as possible; we need to start 
adding those in qt(5).git and packages now to be able to get those in well 
before feature freeze.

br,
Jani Heikkinen
Release Manager
___
Releasing mailing list
releas...@qt-project.org
https://lists.qt-project.org/listinfo/releasing
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Mac Big Sur - Qt Open-Source Support For

[Tuukka Turunen]

Hi,

Supporting Apple silicon is something we are actively working to have in place 
for Qt 6.2 including full CI coverage etc.

To some extent things will work also with Qt 5.15 if you build yourself, but 
there are some rough edges (and Qt 5.15 is not tested for M1).

Yours,

Tuukka

From: Interest  on behalf of Nuno Santos 

Date: Friday, 7. May 2021 at 13.10
To: Tor Arne Vestbø 
Cc: Qt development mailing list , Qt Interest 

Subject: Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For
Tor,

What about building Qt 5.15.X for M1 Macs?

Is there any kind of wiki resource out there?

Regards,

Nuno


On 7 May 2021, at 10:47, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

Qt 6.0 and above has official support for Big Sur:

https://doc.qt.io/archives/qt-6.0/macos.html

5.15 is not yet officially supported, but should work fine as well, so please 
report any issues in JIRA, thanks!

Cheers,
Tor Arne


On 7 May 2021, at 11:00, coroberti 
mailto:corobe...@gmail.com>> wrote:

Dear Tukka and others,
Since September Big Sur is a reality.

Which Qt-version supports correctly QWidgets for this platform for
open-source development.

If there's no such version, when the support is planned if ever.

I'd appreciate not to hijack this question for any discussions beyond the
very narrow scope of this question.

Thanks,

Kind regards,
Robert
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Interest mailing list
inter...@qt-project.org
https://lists.qt-project.org/listinfo/interest

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Status of the QtFeedback module

[Tuukka Turunen]

Hi,

We can increase the test coverage (e.g. additional CI configurations) and if 
needed it is possible to have the playground and other modules to be packaged 
into a ‘release’ source package. Typically users are simply pulling from the 
repos directly, though.

If the module is not tightly coupled to other modules and mostly using the 
public API it is not prone to break easily with new releases of Qt rolling out. 
The main item of concern is the level of maintenance being clear to the users. 
For this reason we are a bit conservative in adding the new libraries to 
binaries. Longer term the goal is to make this more versatile with a package 
manager solution.

Yours,

Tuukka

From: Development  on behalf of Chris Adams 

Date: Thursday, 6. May 2021 at 7.06
To: Aleix Pol 
Cc: Qt Development List 
Subject: Re: [Development] Status of the QtFeedback module
Hi Aleix,

Comments inline.

On Thu, May 6, 2021 at 12:43 AM Aleix Pol 
mailto:aleix...@kde.org>> wrote:
On Tue, Apr 27, 2021 at 2:28 AM Chris Adams 
mailto:chris.ad...@qinetic.com.au>> wrote:
>
> Hi Jonah,
>
> I'm not part of the Qt Company, so please consider my comments as discussion 
> only ;-)
>
> I'm the maintainer of the QtFeedback module, at least insofar as I am willing 
> to review commits and keep things building.  Sailfish OS uses this module, 
> which is why I am still interested in keeping it working etc.  Specifically 
> in the case of QtFeedback, there has been no active development on it for a 
> long time, as you mention, although no doubt many improvements would be 
> possible given that we probably need not maintain BC/SC at this point...  
> Given that the rate of change in the repository is so slow, why is packaging 
> from git snapshot difficult in this case?  And what sort of development do 
> you see likely to occur, should it move under the KDE umbrella instead (and, 
> out of curiosity, why could that development not occur under the Qt project?)
>
> Best regards,
> Chris.
>
>
> On Sat, Apr 24, 2021 at 7:12 AM Jonah Brüchert 
> mailto:j...@kaidan.im>> wrote:
>>
>> Hi,
>>
>> I'm one of the people working on the Plasma Mobile project. We are using
>> the QtFeedback module, and it would be very useful for us to have a
>> release of the module, as packaging git snapshots is making life harder
>> than necessary for packagers. I'm aware the module is currently not
>> actively developed, but it is commonly used in other mobile user
>> interfaces. Are there any plans for it?
>>
>> If the Qt project is no longer interested in the module, we would
>> consider developing it under the KDE umbrella. If you are also using the
>> module, I'd be interested in which backend you are using, so we don't

(Oops, I guess I forgot to respond to this from the original email:
https://git.sailfishos.org/mer-core/qt-mobility-haptics-ffmemless)

>> end up with multiple forks but ideally something like a KDE tier 1
>> framework that anyone can use just like right now.
>>
>> Thanks,
>>
>> Jonah

I guess the biggest problem here is that the Qt project is not
releasing this component, so we're in a weird position when it comes
to developing it further.

Do you mean binary release, or just some version bump and tag?
Would you expect e.g. BC/SC guarantees (I assume so)?
Would you want the major version to be that of Qt (e.g. 6) or separate?

What is required (from Qt Project) to make releases of such a module?
(I guess it's an add-on module, or perhaps even considered a labs module.)
Is it possible for someone not employed by The Qt Company
(e.g. me, for example) to do whatever is required to make releases for
this module (e.g. just by tagging things appropriately to trigger CI machinery),
or is it something which requires internal access?

If it moved to KDE, we could issue releases. If Qt project decides
that it's an interesting module and decides to release it, then that
could work as well.

I wonder if someone from The Qt Company (maybe Alex Blasche?) would
have some thoughts here?  E.g. depending on what is required to make
releases, it could be something which requires either very little work from
The Qt Company, or it could be something which requires substantial work...

>From my (admittedly biased) perspective, it seems like this is something
that does have value for the Qt community, since there are obviously at
least two prominent projects which are relying on this Qt module currently.
So, from that point of view, it would be nice if the Qt Project could make
releases, if that is the primary stumbling block for existing users and
contributors such as Plasma Mobile.

We just need to get it out of this odd freeze in time it's in right now.

Yep, I agree.  Thanks to Jonah and yourself for raising it, hopefully we
can at least define a concrete plan to move forward (either within the
Qt Project or within KDE if that proves to be the pragmatic option).

Best regards,
Chris.


Aleix
___

[Development] Shipping additional libraries as binaries with Qt 6.1

[Tuukka Turunen]

Hi,

We are planning to deliver binaries of additional libraries via the online 
installer starting from Qt 6.1 beta 3, i.e. revert back to the model used with 
Qt 5. Despite the improvements achieved with Creator 4.15 and Qt 6.1 for the 
package manager functionality the approach introduced with Qt 6.0 for 
additional libraries is not providing as good developer experience as desired.

With Qt 6.0 we introduced a hybrid model using online installer for common 
parts of Qt and Conan package manager for additional libraries (distributed in 
source code), described at 
https://www.qt.io/blog/qt-6-additional-libraries-via-package-manager. The 
hybrid model is planned to continue throughout the Qt 6.0.x series, but no 
longer for Qt 6.1.x.

Work continues for realizing the package manager vision in parallel with the 
online installer approach.

Yours,

Tuukka


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] [Releasing] download.qt.io is down

[Tuukka Turunen]

Hi,

This mail was already sent earlier to the list.

Bugreport link is still valid. In case of issues, file a bug.

Yours,

Tuukka

From: Development 
Date: Friday, 5. February 2021 at 10.11
To: Alexandre Ribeiro 
Cc: Qt Project Development , Interests Qt 

Subject: Re: [Development] [Interest] [Releasing] download.qt.io is down

Hi,

There are some items still not fully working in the system for example related 
to being able to provide the right/best mirror.

Please file a bug with details. That is typically the best approach to help 
find out what is going wrong.

Direct link for filing a bug for the right component:

https://bugreports.qt.io/secure/CreateIssueDetails!init.jspa?pid=10510=1=19211

Yours,

Tuukka

From: Alexandre Ribeiro 
Date: Wednesday, 27. January 2021 at 14.24
To: Tuukka Turunen 
Cc: Qt Project Development , Interests Qt 

Subject: Re: [Interest] [Development] [Releasing] download.qt.io is down
Hi,

There are still issues with the online installer:



And if you go to 
https://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/
 the 2020-12-03-0501_meta.7z file is indeed missing.

Are there any workarounds for this issue?

Thanks,
Alex

On Fri, Jan 22, 2021 at 2:30 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Servers have been restored and open-source downloads are working again.

Archive of old and historic releases is missing, but will be made available 
next week.

Blog post: https://www.qt.io/blog/open-source-downloads-working-again

Yours,

Tuukka

From: coroberti mailto:corobe...@gmail.com>>
Date: Friday, 22. January 2021 at 11.32
To: Nils Jeisecke 
mailto:nils.jeise...@saltation.com>>, Tuukka 
Turunen mailto:tuukka.turu...@qt.io>>, Qt Project 
Development mailto:development@qt-project.org>>
Subject: Re: [Development] [Releasing] [Interest] 
download.qt.io<http://download.qt.io> is down
On Fri, Jan 22, 2021 at 10:38 AM Nils Jeisecke via Development
mailto:development@qt-project.org>> wrote:
>
> Hi there,
>
> On Fri, Jan 22, 2021 at 7:59 AM Tuukka Turunen 
> mailto:tuukka.turu...@qt.io>> wrote:
>>
>> Hi,
>>
>>
>>
>> Status update of the problem with open-source downloads: Last night we 
>> finally got a disk big enough for the packages from the service provider. 
>> Most of the data has been transferred throughout the night with a few last 
>> things still being uploaded to the new virtual server. After the data 
>> transfer is complete we start testing and validation of the data and the 
>> system. Target is to enable first the online installer, then the offline 
>> packages and finally the achieve of old releases.
>
>
> just a little "Thank You" from my side.
>
> I try to imagine being of those spending hour after hour to get things 
> running again and then reading all those nasty comments on the blog post.
>
> Nils

Joining the thanks of Nils.
We are really appreciating your support of open-source distribution.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
inter...@qt-project.org<mailto:inter...@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] [Releasing] download.qt.io is down

[Tuukka Turunen]

Hi,

There are some items not fully working in the system for example related to 
being able to provide the right/best mirror.

Please file a bug with details. That is typically the best approach to help 
find out what is going wrong.

Direct link for filing a bug for the right component:

https://bugreports.qt.io/secure/CreateIssueDetails!init.jspa?pid=10510=1=19211

Yours,

Tuukka


From: Alexandre Ribeiro 
Date: Wednesday, 27. January 2021 at 14.24
To: Tuukka Turunen 
Cc: Qt Project Development , Interests Qt 

Subject: Re: [Interest] [Development] [Releasing] download.qt.io is down
Hi,

There are still issues with the online installer:



And if you go to 
https://download.qt.io/online/qtsdkrepository/mac_x64/desktop/tools_maintenance/
 the 2020-12-03-0501_meta.7z file is indeed missing.

Are there any workarounds for this issue?

Thanks,
Alex

On Fri, Jan 22, 2021 at 2:30 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Servers have been restored and open-source downloads are working again.

Archive of old and historic releases is missing, but will be made available 
next week.

Blog post: https://www.qt.io/blog/open-source-downloads-working-again

Yours,

Tuukka

From: coroberti mailto:corobe...@gmail.com>>
Date: Friday, 22. January 2021 at 11.32
To: Nils Jeisecke 
mailto:nils.jeise...@saltation.com>>, Tuukka 
Turunen mailto:tuukka.turu...@qt.io>>, Qt Project 
Development mailto:development@qt-project.org>>
Subject: Re: [Development] [Releasing] [Interest] 
download.qt.io<http://download.qt.io> is down
On Fri, Jan 22, 2021 at 10:38 AM Nils Jeisecke via Development
mailto:development@qt-project.org>> wrote:
>
> Hi there,
>
> On Fri, Jan 22, 2021 at 7:59 AM Tuukka Turunen 
> mailto:tuukka.turu...@qt.io>> wrote:
>>
>> Hi,
>>
>>
>>
>> Status update of the problem with open-source downloads: Last night we 
>> finally got a disk big enough for the packages from the service provider. 
>> Most of the data has been transferred throughout the night with a few last 
>> things still being uploaded to the new virtual server. After the data 
>> transfer is complete we start testing and validation of the data and the 
>> system. Target is to enable first the online installer, then the offline 
>> packages and finally the achieve of old releases.
>
>
> just a little "Thank You" from my side.
>
> I try to imagine being of those spending hour after hour to get things 
> running again and then reading all those nasty comments on the blog post.
>
> Nils

Joining the thanks of Nils.
We are really appreciating your support of open-source distribution.

Kind regards,
Robert Iakobashvili

___
Interest mailing list
inter...@qt-project.org<mailto:inter...@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

Servers have been restored and open-source downloads are working again.

Archive of old and historic releases is missing, but will be made available 
next week.

Blog post: https://www.qt.io/blog/open-source-downloads-working-again

Yours,

Tuukka

From: coroberti 
Date: Friday, 22. January 2021 at 11.32
To: Nils Jeisecke , Tuukka Turunen 
, Qt Project Development 
Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
On Fri, Jan 22, 2021 at 10:38 AM Nils Jeisecke via Development
 wrote:
>
> Hi there,
>
> On Fri, Jan 22, 2021 at 7:59 AM Tuukka Turunen  wrote:
>>
>> Hi,
>>
>>
>>
>> Status update of the problem with open-source downloads: Last night we 
>> finally got a disk big enough for the packages from the service provider. 
>> Most of the data has been transferred throughout the night with a few last 
>> things still being uploaded to the new virtual server. After the data 
>> transfer is complete we start testing and validation of the data and the 
>> system. Target is to enable first the online installer, then the offline 
>> packages and finally the achieve of old releases.
>
>
> just a little "Thank You" from my side.
>
> I try to imagine being of those spending hour after hour to get things 
> running again and then reading all those nasty comments on the blog post.
>
> Nils

Joining the thanks of Nils.
We are really appreciating your support of open-source distribution.

Kind regards,
Robert Iakobashvili

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

Status update of the problem with open-source downloads: Last night we finally 
got a disk big enough for the packages from the service provider. Most of the 
data has been transferred throughout the night with a few last things still 
being uploaded to the new virtual server. After the data transfer is complete 
we start testing and validation of the data and the system. Target is to enable 
first the online installer, then the offline packages and finally the achieve 
of old releases.

Yours,

Tuukka

From: Development 
Date: Thursday, 21. January 2021 at 18.08
To: Qt Project Development 
Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
Hi,

Status update on the open-source distribution topic is that we are still 
waiting for the cloud service provider. Today they been able to provide us with 
new virtual machines for the distribution, but not yet big enough disk space 
for the release data. As soon as we have the disk available, we can start 
transferring the release packages to it, test that everything works and put the 
system back online.

Yours,

Tuukka


From: Sze Howe Koh 
Date: Wednesday, 20. January 2021 at 16.09
To: Tuukka Turunen 
Cc: Qt Project Development 
Subject: Re: [Releasing] [Interest] download.qt.io is down
Thank you for clarifying, Tuukka.

I am (along with many others, I'm sure) delighted to hear about the
upcoming ability to officially select mirrors, and look forward to an
improved download experience going forward. MirrorBrain does not
always pick the best source. [1]

Best of luck with setting up an alternative file server.


Regards,
Sze-Howe

[1] https://lists.qt-project.org/pipermail/development/2018-April/032461.html


On Wed, 20 Jan 2021 at 18:35, Tuukka Turunen  wrote:
>
> Hi,
>
>
>
> To explain a bit why I was mistaken about the online in the mail I sent last 
> night. We have a development feature that allows selecting the mirror 
> manually. I thought it could be used, but it turned out we had not released 
> that version of the installer. Would have been handy, but since it is not 
> already released, the best approach is to re-create the master. We are doing 
> that now. We will also have this feature in the installer released (after we 
> can again make releases), because it is sometimes handy to tell explicitly 
> what server to download from.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> From: Development 
> Date: Wednesday, 20. January 2021 at 8.06
> To: Sze Howe Koh 
> Cc: development@qt-project.org , 
> releas...@qt-project.org , Interests Qt 
> 
> Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
>
> Hi,
>
>
>
> Yes, this is correct.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> From: Sze Howe Koh 
> Date: Wednesday, 20. January 2021 at 0.10
> To: Tuukka Turunen 
> Cc: Mark Long , development@qt-project.org 
> , Interests Qt , 
> releas...@qt-project.org 
> Subject: Re: [Releasing] [Interest] download.qt.io is down
>
> On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen  wrote:
> >
> >
> > Hi,
> >
> > There are multiple mirrors, try for example:
> >
> >
> >
> > https://qt-mirror.dannhauer.de/
> >
> > https://www.funet.fi/pub/mirrors/download.qt-project.org/
> >
> > https://ftp.fau.de/qtproject/
> >
> >
> >
> > ...or just use the online installer, which picks mirrors automatically.
> >
> > Yours,
> >
> > Tuukka
>
> Hi Tuuka,
>
> The Online installer downloads files in 2 phases:
>
> 1. Retrieve metadata from download.qt.io
> 2. Retrieve actual binaries from the auto-selected mirror
>
> Since Step #1 is blocked, it can't proceed to Step #2.
>
>
> Regards,
> Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

Status update on the open-source distribution topic is that we are still 
waiting for the cloud service provider. Today they been able to provide us with 
new virtual machines for the distribution, but not yet big enough disk space 
for the release data. As soon as we have the disk available, we can start 
transferring the release packages to it, test that everything works and put the 
system back online.

Yours,

Tuukka


From: Sze Howe Koh 
Date: Wednesday, 20. January 2021 at 16.09
To: Tuukka Turunen 
Cc: Qt Project Development 
Subject: Re: [Releasing] [Interest] download.qt.io is down
Thank you for clarifying, Tuukka.

I am (along with many others, I'm sure) delighted to hear about the
upcoming ability to officially select mirrors, and look forward to an
improved download experience going forward. MirrorBrain does not
always pick the best source. [1]

Best of luck with setting up an alternative file server.


Regards,
Sze-Howe

[1] https://lists.qt-project.org/pipermail/development/2018-April/032461.html


On Wed, 20 Jan 2021 at 18:35, Tuukka Turunen  wrote:
>
> Hi,
>
>
>
> To explain a bit why I was mistaken about the online in the mail I sent last 
> night. We have a development feature that allows selecting the mirror 
> manually. I thought it could be used, but it turned out we had not released 
> that version of the installer. Would have been handy, but since it is not 
> already released, the best approach is to re-create the master. We are doing 
> that now. We will also have this feature in the installer released (after we 
> can again make releases), because it is sometimes handy to tell explicitly 
> what server to download from.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> From: Development 
> Date: Wednesday, 20. January 2021 at 8.06
> To: Sze Howe Koh 
> Cc: development@qt-project.org , 
> releas...@qt-project.org , Interests Qt 
> 
> Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
>
> Hi,
>
>
>
> Yes, this is correct.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> From: Sze Howe Koh 
> Date: Wednesday, 20. January 2021 at 0.10
> To: Tuukka Turunen 
> Cc: Mark Long , development@qt-project.org 
> , Interests Qt , 
> releas...@qt-project.org 
> Subject: Re: [Releasing] [Interest] download.qt.io is down
>
> On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen  wrote:
> >
> >
> > Hi,
> >
> > There are multiple mirrors, try for example:
> >
> >
> >
> > https://qt-mirror.dannhauer.de/
> >
> > https://www.funet.fi/pub/mirrors/download.qt-project.org/
> >
> > https://ftp.fau.de/qtproject/
> >
> >
> >
> > ...or just use the online installer, which picks mirrors automatically.
> >
> > Yours,
> >
> > Tuukka
>
> Hi Tuuka,
>
> The Online installer downloads files in 2 phases:
>
> 1. Retrieve metadata from download.qt.io
> 2. Retrieve actual binaries from the auto-selected mirror
>
> Since Step #1 is blocked, it can't proceed to Step #2.
>
>
> Regards,
> Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

Short status update on this. The cloud service provider providing the hosting 
of these two servers has informed us that they are still facing challenges with 
getting the new virtual machines up and running. This is caused by the large 
number of affected machines that they need to re-create (we were not the only 
one affected by this hardware failure). Therefore it is unlikely that we are 
able to get the system back online today. We are also checking alternative 
options like using another service provider or our own machine room in the same 
capacity where CI and related development systems are running.

Yours,

Tuukka

From: Development 
Date: Wednesday, 20. January 2021 at 12.44
To: Sze Howe Koh 
Cc: Qt Project Development 
Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
Hi,

To explain a bit why I was mistaken about the online in the mail I sent last 
night. We have a development feature that allows selecting the mirror manually. 
I thought it could be used, but it turned out we had not released that version 
of the installer. Would have been handy, but since it is not already released, 
the best approach is to re-create the master. We are doing that now. We will 
also have this feature in the installer released (after we can again make 
releases), because it is sometimes handy to tell explicitly what server to 
download from.

Yours,

Tuukka

From: Development 
Date: Wednesday, 20. January 2021 at 8.06
To: Sze Howe Koh 
Cc: development@qt-project.org , 
releas...@qt-project.org , Interests Qt 

Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
Hi,

Yes, this is correct.

Yours,

Tuukka

From: Sze Howe Koh 
Date: Wednesday, 20. January 2021 at 0.10
To: Tuukka Turunen 
Cc: Mark Long , development@qt-project.org 
, Interests Qt , 
releas...@qt-project.org 
Subject: Re: [Releasing] [Interest] download.qt.io is down
On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen  wrote:
>
>
> Hi,
>
> There are multiple mirrors, try for example:
>
>
>
> https://qt-mirror.dannhauer.de/
>
> https://www.funet.fi/pub/mirrors/download.qt-project.org/
>
> https://ftp.fau.de/qtproject/
>
>
>
> ...or just use the online installer, which picks mirrors automatically.
>
> Yours,
>
> Tuukka

Hi Tuuka,

The Online installer downloads files in 2 phases:

1. Retrieve metadata from download.qt.io
2. Retrieve actual binaries from the auto-selected mirror

Since Step #1 is blocked, it can't proceed to Step #2.


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

To explain a bit why I was mistaken about the online in the mail I sent last 
night. We have a development feature that allows selecting the mirror manually. 
I thought it could be used, but it turned out we had not released that version 
of the installer. Would have been handy, but since it is not already released, 
the best approach is to re-create the master. We are doing that now. We will 
also have this feature in the installer released (after we can again make 
releases), because it is sometimes handy to tell explicitly what server to 
download from.

Yours,

Tuukka

From: Development 
Date: Wednesday, 20. January 2021 at 8.06
To: Sze Howe Koh 
Cc: development@qt-project.org , 
releas...@qt-project.org , Interests Qt 

Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down
Hi,

Yes, this is correct.

Yours,

Tuukka

From: Sze Howe Koh 
Date: Wednesday, 20. January 2021 at 0.10
To: Tuukka Turunen 
Cc: Mark Long , development@qt-project.org 
, Interests Qt , 
releas...@qt-project.org 
Subject: Re: [Releasing] [Interest] download.qt.io is down
On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen  wrote:
>
>
> Hi,
>
> There are multiple mirrors, try for example:
>
>
>
> https://qt-mirror.dannhauer.de/
>
> https://www.funet.fi/pub/mirrors/download.qt-project.org/
>
> https://ftp.fau.de/qtproject/
>
>
>
> ...or just use the online installer, which picks mirrors automatically.
>
> Yours,
>
> Tuukka

Hi Tuuka,

The Online installer downloads files in 2 phases:

1. Retrieve metadata from download.qt.io
2. Retrieve actual binaries from the auto-selected mirror

Since Step #1 is blocked, it can't proceed to Step #2.


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

Yes, this is correct.

Yours,

Tuukka

From: Sze Howe Koh 
Date: Wednesday, 20. January 2021 at 0.10
To: Tuukka Turunen 
Cc: Mark Long , development@qt-project.org 
, Interests Qt , 
releas...@qt-project.org 
Subject: Re: [Releasing] [Interest] download.qt.io is down
On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen  wrote:
>
>
> Hi,
>
> There are multiple mirrors, try for example:
>
>
>
> https://qt-mirror.dannhauer.de/
>
> https://www.funet.fi/pub/mirrors/download.qt-project.org/
>
> https://ftp.fau.de/qtproject/
>
>
>
> ...or just use the online installer, which picks mirrors automatically.
>
> Yours,
>
> Tuukka

Hi Tuuka,

The Online installer downloads files in 2 phases:

1. Retrieve metadata from download.qt.io
2. Retrieve actual binaries from the auto-selected mirror

Since Step #1 is blocked, it can't proceed to Step #2.


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

You are probably right.

Let’s see tomorrow how to best tackle this.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Thiago 
Macieira  puolesta
Lähetetty: Tuesday, January 19, 2021 11:08:39 PM
Vastaanottaja: development@qt-project.org 
Aihe: Re: [Development] [Interest] download.qt.io is down

On Tuesday, 19 January 2021 12:08:57 PST Tuukka Turunen wrote:
> ...or just use the online installer, which picks mirrors automatically.

Where does it get the list of mirrors from?

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
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

Re: [Development] [Interest] download.qt.io is down

[Tuukka Turunen]

Hi,

There are multiple mirrors, try for example:



https://qt-mirror.dannhauer.de/

https://www.funet.fi/pub/mirrors/download.qt-project.org/

https://ftp.fau.de/qtproject/



...or just use the online installer, which picks mirrors automatically.

Yours,

Tuukka


Lähettäjä: Mark Long 
Lähetetty: tiistaina, tammikuuta 19, 2021 9:58 ip.
Vastaanottaja: Tuukka Turunen
Kopio: Jani Heikkinen; development@qt-project.org; releas...@qt-project.org; 
Interests Qt
Aihe: Re: [Interest] download.qt.io is down

It seems that the only mirror list I can find online is served from 
download.qt.io<http://download.qt.io>, which is quite unhelpful at the moment.  
Does anyone have a mirror link handy or a link to another list somewhere else?

Thanks much!
Mark

On Tue, Jan 19, 2021 at 12:59 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:
Hi,

Update on the status. The downtime is caused by severe disk system failure at 
our cloud service provider. The service provider has notified us that they will 
not be able to repair the disk systems during today.

Two important servers related to open-source package delivery are affected 
(download frontend and delivery system master). Mirrors are not affected, so 
online installer works and also offline packages can be downloaded directly 
from the mirrors. Commercial package distribution is done via a different 
system, which is not affected by this.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>>
Date: Tuesday, 19. January 2021 at 11.21
To: development@qt-project.org<mailto:development@qt-project.org> 
mailto:development@qt-project.org>>, 
releas...@qt-project.org<mailto:releas...@qt-project.org> 
mailto:releas...@qt-project.org>>
Subject: [Development] download.qt.io<http://download.qt.io> is down
Hi all,

You have most probably already noticed that 
download.qt.io<http://download.qt.io> is down. We are fixing the issue so 
please be patient. I'll inform you when it should work OK

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
___
Interest mailing list
inter...@qt-project.org<mailto:inter...@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] download.qt.io is down

[Tuukka Turunen]

Hi,

Update on the status. The downtime is caused by severe disk system failure at 
our cloud service provider. The service provider has notified us that they will 
not be able to repair the disk systems during today.

Two important servers related to open-source package delivery are affected 
(download frontend and delivery system master). Mirrors are not affected, so 
online installer works and also offline packages can be downloaded directly 
from the mirrors. Commercial package distribution is done via a different 
system, which is not affected by this.

Yours,

Tuukka

From: Development 
Date: Tuesday, 19. January 2021 at 11.21
To: development@qt-project.org , 
releas...@qt-project.org 
Subject: [Development] download.qt.io is down
Hi all,

You have most probably already noticed that download.qt.io is down. We are 
fixing the issue so please be patient. I'll inform you when it should work OK

br,
Jani Heikkinen
Release Manager
___
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

Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Tuukka Turunen]

Hi Nico,

Basic “rule of thumb” is that if a commercial Qt license holder has access to 
Qt 5.15 in general, s/he also gets Qt 5.15.3 provided that the license is 
active at the time of Qt 5.15.3 release.

Yours,

Tuukka

From: Wallmeier, Nico 
Date: Monday, 4. January 2021 at 17.33
To: Tuukka Turunen , Qt Development ML 

Subject: RE: [Development] Commercial-only LTS phase starts: Closing the 5.15 
branch(es) on 5th January
Hi Tukka,

what do you mean by “commercial only” exactly? Is Qt 5.15.3 only included in 
the subscription or is it also included in an active perpetual license?

Kind regards,
Nico Wallmeier

From: Development  On Behalf Of Tuukka 
Turunen
Sent: Montag, 4. Januar 2021 15:57
To: Roland Winklmeier ; Qt Development ML 

Subject: Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 
branch(es) on 5th January


Hi Roland,

Just so that there is no misunderstanding Qt 5.15.2 release stays available for 
all users, it is just the upcoming LTS phase patch releases that will be 
commercial only. In essence for the open-source users Qt 5.15 is similar to Qt 
5.13 and Qt 5.14 (non-LTS releases).

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>>
Date: Monday, 4. January 2021 at 16.33
To: Qt Development ML 
mailto:development@qt-project.org>>
Subject: Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 
branch(es) on 5th January
Am Mo., 4. Jan. 2021 um 14:38 Uhr schrieb Benjamin TERRIER 
mailto:b.terr...@gmail.com>>:


On Mon, 4 Jan 2021 at 14:14, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:
On Mon, Jan 04, 2021 at 10:55:03AM +, Tuukka Turunen wrote:
>With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming
>soon, it is time to enter the commercial-only LTS phase for Qt 5.15
>LTS.
>
that's some brilliant timing, given that no actual qt 6 release even
exists yet. (yeah, 6.0 is a joke given that you intend to break binary
compat in 6.1 - that's the wisdom of linking r's bonus payments to
release dates even for major versions).

Yes, it would have made sense that the Qt Company waits for all modules to be 
available in Qt 6 before dropping the 5.15 open support...

I cannot express how much I agree to this. Qt6 has half of the modules required 
by my project not yet available, so upgrading is not possible. On the other 
hand, 5.15 LTS is closed for the open source users - this is quite a heavy 
restriction for me since my project is non-profit and open source. Buying a 
commercial license is not an option.
Yes I'm aware that I'm a small fish in a large pond and QtC won't care about my 
contributions or me as a developer using Qt since there is no profit to make 
with me. On the other hand, I will carefully think about using Qt again in 
future projects or recommend it to other people.
This is not a complaint. Its your business and your rules. I'm just trying to 
express the thoughts of a bigger but usally silent group of open 
source/non-profit users which are directly impacted by this.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Tuukka Turunen]

Hi Roland,

Just so that there is no misunderstanding Qt 5.15.2 release stays available for 
all users, it is just the upcoming LTS phase patch releases that will be 
commercial only. In essence for the open-source users Qt 5.15 is similar to Qt 
5.13 and Qt 5.14 (non-LTS releases).

Yours,

Tuukka

From: Development 
Date: Monday, 4. January 2021 at 16.33
To: Qt Development ML 
Subject: Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 
branch(es) on 5th January
Am Mo., 4. Jan. 2021 um 14:38 Uhr schrieb Benjamin TERRIER 
mailto:b.terr...@gmail.com>>:


On Mon, 4 Jan 2021 at 14:14, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:
On Mon, Jan 04, 2021 at 10:55:03AM +0000, Tuukka Turunen wrote:
>With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming
>soon, it is time to enter the commercial-only LTS phase for Qt 5.15
>LTS.
>
that's some brilliant timing, given that no actual qt 6 release even
exists yet. (yeah, 6.0 is a joke given that you intend to break binary
compat in 6.1 - that's the wisdom of linking r's bonus payments to
release dates even for major versions).

Yes, it would have made sense that the Qt Company waits for all modules to be 
available in Qt 6 before dropping the 5.15 open support...

I cannot express how much I agree to this. Qt6 has half of the modules required 
by my project not yet available, so upgrading is not possible. On the other 
hand, 5.15 LTS is closed for the open source users - this is quite a heavy 
restriction for me since my project is non-profit and open source. Buying a 
commercial license is not an option.
Yes I'm aware that I'm a small fish in a large pond and QtC won't care about my 
contributions or me as a developer using Qt since there is no profit to make 
with me. On the other hand, I will carefully think about using Qt again in 
future projects or recommend it to other people.
This is not a complaint. Its your business and your rules. I'm just trying to 
express the thoughts of a bigger but usally silent group of open 
source/non-profit users which are directly impacted by this.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Tuukka Turunen]

Hi,

This is well understandable and expected. The Qt Company is prepared to handle 
the Qt 5.15 LTS phase work. I wanted to ask if there is interest, as there may 
be some external maintainers who are interested in what goes into the 
commercial-only LTS releases e.g. due to having customers using those.

Yours,

Tuukka

From: Development 
Date: Monday, 4. January 2021 at 15.01
To: Qt development mailing list 
Subject: Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 
branch(es) on 5th January
Tend to agree with Thiago.
If there is a decision to close 5.15 sources, there'll be no more work from 
external/unpaid contributors.

Regards,
Konstantin


пн, 4 янв. 2021 г. в 15:21, Thiago Macieira 
mailto:thiago.macie...@intel.com>>:
On Monday, 4 January 2021 07:55:03 -03 Tuukka Turunen wrote:
> We can arrange access for external module maintainers to the commercial-only
> repositories. If there is interest, please contact me or Tarja Sundqvist
> tarja.sundqv...@qt.io<mailto:tarja.sundqv...@qt.io><mailto:tarja.sundqv...@qt.io<mailto:tarja.sundqv...@qt.io>>
>  who is the release
> manager for the commercial-only LTS releases.

There is no interest in on part.

That means I will not be participating in the development of those fixes,
commenting on what's appropriate or not, reviewing backports, or bug reports.
In fact, bug reports that cannot be reproduced on 6.0 will also be closed.

--
Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com>
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org<mailto: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

[Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Tuukka Turunen]

Hi,

With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming soon, it 
is time to enter the commercial-only LTS phase for Qt 5.15 LTS. All the 
existing 5.15 branches remain publicly visible, but they are closed for new 
commits (and cherry-picks). Exception being the Qt WebEngine (and the 
deprecated Qt Script), which have a 3rd party LGPL dependency.

Closing happens tomorrow, 5th January 2021. After this the cherry-picks go to 
another repository that will be available only for the commercial license 
holders. We will arrange repository access to the commercial license holders, 
so in addition to the official releases it is possible to use the repositories. 
Instructions about this will be available to commercial license holders during 
next week, after we have completed the license change and other preparations.

First commercial-only Qt 5.15.3 LTS patch release is planned to be released in 
February.

We can arrange access for external module maintainers to the commercial-only 
repositories. If there is interest, please contact me or Tarja Sundqvist 
tarja.sundqv...@qt.io who is the release manager 
for the commercial-only LTS releases.

Yours,

Tuukka



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6.0.x releasing and Qt 6.0.x changes files

[Tuukka Turunen]

+1

From: Development 
Date: Tuesday, 22. December 2020 at 10.33
To: development@qt-project.org 
Subject: Re: [Development] Qt 6.0.x releasing and Qt 6.0.x changes files
Hi,

Lars made a new proposal, see his comment in 
https://codereview.qt-project.org/c/qt/qtbase/+/324440

Basic idea would be
   * We will create one release note for the release instead of separate 
changes file in each submodule
   * Release notes are stored in separate release notes git repository. That 
way we can freeze Qt release content & generate ( and finalize) release notes 
after the content freeze
   * We will remove dist/ folder in our current repos

All that would be doable also in Qt 6.0.1 schedule (except of fully automated 
release note generation but that can be solved independently later) so at least 
I will support this Lars proposal. Any comments?

br,
Jani  Heikkinen

> -Original Message-
> From: Development  On Behalf Of
> Jani Heikkinen
> Sent: tiistai 1. joulukuuta 2020 11.01
> To: development@qt-project.org
> Subject: [Development] Qt 6.0.x releasing and Qt 6.0.x changes files
>
> Hi all,
>
> Qt 6.0.0 should be out really soon and it is time to start planning upcoming
> patch level releases for the Qt 6.0 series. Plan is to release quick updates 
> for
> the Qt 6.0 pretty much similarly than we did in the beta phase. It means
> there should be a new Qt 6.0.x patch release once / 2-3 weeks. That way we
> could get regular updates to the users & releasing should be quite easy due
> to the limited set of changes. We could even do these patch releases directly
> from the '6.0' branch if we want...
>
> But how to create changes files for the modules with this process? If we
> need to freeze the release content, generate initial changes files, finalize
> those, review, integrate, etc this new process won't work; it just takes a too
> long time to complete. So we need to get those changes files in the packages
> automatically or just stop updating those in the git and attach those in the
> release some other way.
>
> Would it be ok to add a general Qt 6.0.x changes file in each module
> (something like this: https://codereview.qt-
> project.org/c/qt/qtbase/+/324440 ) and also add a pure change list in the
> wiki? That would be a lightweight process & makes regular, quick patch level
> releases possible.
>
> Thoughts?
>
> Br,
> Jani Heikkinen
> Release Manager
> ___
> 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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6.0 RC and timelines for 6.1 and 6.2

[Tuukka Turunen]

Hi,

Qt 6.2 would be the one that becomes long-term supported (for commercial 
license holders) when we keep the cadence of every 3rd release.

Yours,

Tuukka

From: Development 
Date: Sunday, 29. November 2020 at 20.41
To: development@qt-project.org 
Subject: Re: [Development] Qt 6.0 RC and timelines for 6.1 and 6.2
Hi,

On 27/11/2020 12:56, Lars Knoll wrote:
> So the idea is to shorten the release cycle for Qt 6.1 a bit and focus mainly 
> on bug fixing and stability for that release. We’d aim for a feature freeze 
> by the end of January, and a final Qt 6.1.0 release end of April.
>
> 6.2 would then also happen a bit earlier, with a feature freeze in June and a 
> release end of September.

Thanks for sharing this plan!

I'm wondering, are LTS releases something already discussed? Do you see
6.3 (?) as the first Qt 6 LTS?


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Building additional components with Conan for Qt 6

[Tuukka Turunen]

Hi Richard,

Like Iikka wrote the primary plan is to leverage package manager to make it 
easier to work with additional components. We now have two Qt add-ons (Qt 
Network Authorization and Qt Image Formats) to test with. Our thinking is that 
the Qt installer is still the way to get the baseline Qt, but we aim to provide 
additional items via package manager. 

We are still in the early steps and things like integration to tooling is 
something that we need to work on. There are also many items that we do not yet 
know what works the best, and we want to develop this further to reach a good 
end user experience also when it comes to the tooling, discovery of additional 
libraries etc. 

The idea is that the additional libraries available via the package manager are 
available in source code and built locally. The pre-built binaries continue to 
be delivered via the Qt installer. Our intention is to store the recipes into 
the component source repo root, but these are not in-place yet.

Yours,

Tuukka

On 1.10.2020, 16.08, "Development on behalf of Richard Weickelt" 
 wrote:

Hello Ilkka,

thanks for the heads up. I have some further questions:

1. Will Conan be used to manage dependencies of Qt as well?
2. How will the recipes be managed and where on code.qt.io can I find them?
3. Is TQtC going to host a Conan repository for binary packages as well?
4. What is the Qt Company's position regarding conan-center?

Thanks
BR
Richard Weickelt
___
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

Re: [Development] Feature freeze next Tuesday

[Tuukka Turunen]

Hi,

Do you have some estimate how long time is needed to get these in?

Also, do you foresee any issues these changes may cause to others? 

Yours,

Tuukka

On 1.9.2020, 11.01, "Development on behalf of Giuseppe D'Angelo via 
Development"  wrote:

Il 26/08/20 08:46, Lars Knoll ha scritto:
> I would hope that there are no other exceptions required. If something is 
not done, but can easily be pushed to 6.1, you know what to do. If anybody 
knows about something else that can’t be pushed please talk to me, so we can 
figure out what to do about it.

I'd like to request an exception for a few patches of mine which have 
been around for a while now:

* QIM::multiData
* QKeyCombination + removal of operator+(QFlags, *)
* (ideally) Qt::SingleShotConnection

The first two have to go in 6.0.

Thanks,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Codereview maintenance break is over

[Tuukka Turunen]

Hi,

Thanks! That was fast. Codereview seems to be working nicely with the new 
version.

Yours,

Tuukka

From: Development  on behalf of Jukka 
Jokiniva 
Date: Monday 24. August 2020 at 8.19
To: Qt Project Development 
Subject: [Development] Codereview maintenance break is over

Hi,

The maintenance break is over.

   --Jukka


From: Development  on behalf of Jukka 
Jokiniva 
Date: Monday 24. August 2020 at 6.53
To: "development@qt-project.org" 
Subject: [Development] Codereview scheduled maintenance break starts in 10 
minutes

Hi,

codereview.qt-project.org scheduled maintenance break starts in 10 minutes

--Jukka

From: Development  on behalf of Jukka 
Jokiniva 
Date: Friday 21. August 2020 at 14.17
To: "development@qt-project.org" 
Subject: [Development] Reminder: Codereview scheduled maintenance break on 
Monday 24-Aug 6 am CET

Just reminder that the codereview.qt-project.org will be offline on Monday 
morning.

--Jukka

From: Development  on behalf of Jukka 
Jokiniva 
Date: Monday 17. August 2020 at 16.02
To: "development@qt-project.org" 
Subject: [Development] Codereview scheduled maintenance break on Monday 24-Aug 
6 am CET

Hi all,

There will be a maintenance break on the codereview.qt-project.org on Monday 
24-Aug 6:00 am – 7:00 am CET.
The Gerrit version will be upgraded from 3.0.2 to 3.1.4.

If you see a problem with the time, please contact me directly.

 --Jukka Jokiniva
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Can your module be included in Qt 6?

[Tuukka Turunen]

Hi Ekke,

We also have new installer cooking up for Qt 6, see: 
https://www.qt.io/blog/qt-online-installer-4.0-pre-alpha-released and 
https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#Qt_Marketplace 

Intention is that including source components becomes convenient. This could 
also allow making some of the add-ons that are not yet fully ready to be 
included as source for users to try out on top of a released set of binaries.

Yours,

Tuukka


On 26.6.2020, 15.19, "Development on behalf of ekke" 
 wrote:

Am 26.06.20 um 13:49 schrieb Tor Arne Vestbø:
>
>> On 26 Jun 2020, at 13:41, ekke  wrote:
>>
>> I have noticed that Qt for Android will take some time - what about iOS 
? Will I be able to port iOS Apps to Qt 6 ? Would help to prepare and test 
mobile apps for Qt6 while waiting for Android.
> Both Android and iOS support is part of 6.0. The part that’s deferred is 
the Android _extras_, the helper module for more native integration on Android. 
But running a cross platform Qt Quick app should work fine on both platforms.
>
> Tor Arne
>
aaah - thanks for the info - so I can take the QtSummit Conference App 
as my first candidate :)

then only other apps with the need of Intents etc have to wait. 
hopefully QtBluetooth will come soon to Qt6, because many of my mobile 
business apps need Bluetooth for mobile BarcodeScanners or Printers.

ekke

___
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

Re: [Development] QtWebEngine and Qt 6 (was: Re: Can your module be included in Qt 6?)

[Tuukka Turunen]

Hi,

The situation with Qt WebEngine open-source releases during the commercial-only 
LTS phase is slightly unclear still as it has a very large 3rd party item it 
depends on. In essence Qt WebEngine is just bindings of the Chromium HTML5 
engine to Qt. Intention is to clarify this before Qt 6.0 is released and the 
commercial-only LTS phase begins. 

Yours,

Tuukka

On 26.6.2020, 13.47, "Development on behalf of Florian Bruhin" 
 wrote:

Hey,

On Fri, Jun 26, 2020 at 09:53:55AM +, Lars Knoll wrote:
> As you can see, the scope of 6.0 will be reduced compared to 5.15.

So now that it's official that QtWebEngine won't be part of Qt 6.0:

What will that mean for security upgrades (i.e. updates of the underlying
Chromium) for open source users of Qt as soon as Qt 6.0 is out?

Given that the 5.15 LTS is restricted to commercial users[1], does that mean
that open source projects will be stuck on Qt 5.15.4 (or .3 or .5 or 
whatever)
until Qt 6.1 is released in May/June 2021 or so?

If that's the case, I'm not sure that'll help Qt's reputation when it comes 
to
its handling of security issues... Don't get me wrong, I can understand 
where
TQtC is coming from with the commercial-only LTS decision - but if there 
are no
QtWebEngine security fixes for open source users at all for what's probably
more than half a year (the time between the last 5.15.x before 6.0; and 
6.1),
that seems like a huge problem, no?

I'm all for "We are making this change to encourage open-source users to
quickly adopt new versions" (from that blog post), but what if that's not
possible because those new versions don't exist at the point the old 
versions
get abandoned? Wouldn't it make a lot of sense to make the 5.15 LTS
commercial-only only at the point Qt 6.1 is released, at least for all 
modules
not part of Qt 6.0?

[1] https://www.qt.io/blog/qt-offering-changes-2020

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Quick Calendar

[Tuukka Turunen]

Hi,

Open-source license freely available from the repo will be GPLv3, but we will 
also provide it under the marketplace license with a very decent price tag 
(allowing to use it with LGPLv3 licensed Qt).

Yours,

Tuukka 

On 17.6.2020, 19.59, "Development on behalf of Vincas Dargis" 
 wrote:

2020-06-17 09:59, Mitch Curtis rašė:
> The Qt Quick Calendar module provides a set of types that can be used to 
build calendars in Qt Quick.

That's really useful! Especially when QCC1 are removed in Qt6...

Though the biggest question is - will it be available in LGPL form?

Thanks!
___
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

Re: [Development] Switch the main "Qt Build System"

[Tuukka Turunen]

Hi,

"Putting that aside, how long should we wait then? " is exactly the question we 
would like to find the answer to __

My own preference is to make the switch to CMake as soon as possible and use 
effort to improving the CMake port instead of keeping the qmake as a parallel 
build system for Qt itself. Having the mixing support as an option is 
beneficial, and something we wanted to offer to the extent feasible without 
risking the overall Qt 6.0 development. 

We are currently at a point where all the most commonly used modules are built 
with CMake. There is a bit less than 3 months to Qt 6.0 feature freeze and 
around 8 months to Qt 6.1 feature freeze. This should be adequate time to make 
the changes in all the relevant modules. 

The goal is for all the Qt 6.0 modules are in place at the Structure and 
platform freeze milestone (end of June, https://wiki.qt.io/Qt_6.0_Release). 
This allows us to have things ready well before the feature freeze - and avoid 
situations where some larger changes are done close to the FF deadline, 
potentially causing instability. We should not accept any modules that are 
still built with qmake to the Qt 6.0 release content. 

So, let's continue the discussion and aim to reach the conclusion in the next 
few days for the best path forward related to the topic. 

Yours,

Tuukka

 

On 9.6.2020, 11.45, "Development on behalf of Alexandru Croitor" 
 wrote:

Hi Andy,

I'll acknowledge that the current Qt Creator <-> Build Qt with CMake 
situation is sub-par.

Though, I believe there is a sketchy config to allow you to use a released 
Qt Creator to develop Qt.


Putting that aside, how long should we wait then? 

I'm not sure if we can afford to delay the switch for much longer, for many 
reasons:

- I don't know how long it would take to improve Creator to do "the right 
thing".
- The Qt releasing team needs to start creating and testing packages based 
on the CMake-built Qt
- Developers are burdened with maintaining 2 build systems (not just the 
CMake port team, but also other developers doing regular Qt6.0 work)

We have to bite the bullet at some point.

> On 9. Jun 2020, at 09:59, Andy Nichols  wrote:
> 
> Hi Alexandru,
> 
> I think Brett touches on the biggest blocker for me and that is actually 
related to Qt Creators ability to open and use modules built using cmake.  I am 
actually really impressed with state of the CMake support for build Qt as it is 
right now, and wish I could more actively use it, but unfortunately my current 
workflow involves using Qt Creator to develop Qt, and I have to work on modules 
that are not just QtBase.  Despite adding my cmake based Qt Builds to Creator 
as kits (which seems to only be possible using qmake), it isn't possible for 
Creator to easily recognize that my module's are built with that kit when 
loading them.  I hear rumors that it is possible, but most of the guys who say 
that are only working on qtbase anyway.
> 
> I think that before we kill the qmake based build of Qt, that our own IDE 
should support developing Qt itself.  And I would be happy with some "sketchy 
config" that works with a released version of Qt Creator for now, but this 
shouldn't be good enough to justify killing qmake before a real solution is in 
place.

___
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

Re: [Development] Qt Multimedia as Add-on in Qt 6

[Tuukka Turunen]

Hi,

There are many add-ons that work perfectly well on mobile. Essentials should be 
such that are as the name suggest essential for the Qt based applications (or 
devices). Furthermore, the essentials need to work on all platforms. This means 
also the embedded and RTOS platforms, not only desktop and mobile.

Yours,

Tuukka 

On 22.5.2020, 17.20, "Development on behalf of Jason H" 
 wrote:

Will this have repercussions in the Maintenance tool?
I don't really think that calling Multimedia an "add on" is a reflection of 
reality, post 1994.
For mobile kits (iOS, Android) these are essential features. Sorry, Qt just 
can't get away with drawing rectangles and text in 2020. I fear this is more 
maligning of mobile by Lars. I think this will result in providing a lower tier 
of service than compared to the "essentials".

I object, and wish multimedia to remain an essential part of Qt. 





> Sent: Friday, May 22, 2020 at 3:47 AM
> From: "Lars Knoll" 
> To: "Giuseppe D'Angelo" 
> Cc: "Qt development mailing list" 
> Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6
>
> Hi,
> 
> > On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development 
 wrote:
> > 
> > Hi,
> > 
> > Il 21/05/20 11:38, Val Doroshchuk ha scritto:
> >> The license is not changed, plans just to not ship QtMultimedia with 
Qt essentials,
> >> can be installed separately. Possibly we also support only a limited 
set of platforms.
> >> Qt Essentials must work on every platform, according to the definition 
of essentials.
> > 
> > While of course it's up to each module maintainer to decide on its 
status (and thus, if QtMM doesn't qualify for "Essentials" any more, can become 
an "Addon"), I'm left wondering why does this imply being moved to the 
Marketplace, out of Qt itself?
> > 
> > 
> > * Is this part of a broader plan, aiming at streamlining the Qt offer 
to just mean Essentials, while the Addons get moved to the marketplace?
> 
> This is something I’ve been at least mentioning at the Contributor Summit 
already. Distributing it through the market place is mainly a different means 
of packaging it and decoupling the release schedules. A user should still be 
able to discover and install Qt MM (or other add-ons delivered through the 
market place) in the installer, just as today.
> 
> But yes, this goes then towards streamlining Qt 6 a bit. Reducing the set 
of things that you have to install, and making more modules optional.
> > 
> > ("Qt offer" is of course inaccurate, given the many offers available, 
but you get my drift...).
> > 
> > 
> > * If so, are all the practical issues for such addons sorted out? First 
few things that come to mind:
> > 
> > 1) Version numbering scheme, release schedule
> 
> This needs some sorting out, I agree.
> 
> > 2) CI testing / platform coverage
> 
> That should be ok for now, although if an add-on targets several Qt 
versions at once, we don’t yet have a good mechanism to deal with that in CI.
> 
> > 3) Compatibility promise (own API/ABI stability, which Qt versions it 
works with, etc.)
> 
> I think it will be good to give add-ons a bit more flexibility there how 
to handle it. This is because different add-ons have rather different 
requirements, that we’ve so long all tried to shoehorn into the Qt release 
process. Compare for example WebEngine that needs frequent updates due to new 
Chromium releases with e.g. Qt SVG that only receives a very limited amount of 
bug fixes.
> 
> > 4) Where to put the docs, release notes, etc.
> 
> Into the package and on the web site as usual.
> > 
> > 
> > * What about the KDE/Qt agreement? Are the list of Essential and Addon 
modules being re-evaluated there as well? QtMM is not really at liberty of 
changing license because it's an "Essential" (in the agreement).
> 
> There’s the agreements legal term, and the status in terms of the 
agreement is something we can’t change without agreement from the board of the 
KDE Free Qt Foundation.
> 
> When the new agreement was done some years ago, we tried to align terms 
with what we had in Qt Project at that time. But things do change and I believe 
we can change what we see as essential and add-on in terms of the project (and 
in the commercial packages) independently of the agreement. 
> 
> This is confusing to some extent as the legal agreement uses the same 
terms as we’re using, but the terms are defined in the agreement itself, and 
limited to the scope of the agreement. They don’t dictate how we package or 
name things in our releases (as long as the conditions set forth in the 
agreement are fulfilled).
> 
> The main thing the agreement mandates is the licensing of add-on and 
essential modules. But the only real difference between add-ons and essentials 

Re: [Development] Finishing the transition to the cherry-pick model

[Tuukka Turunen]

Big thanks to everyone involved.

Yours,

Tuukka

From: Development  on behalf of Volker 
Hilsheimer 
Date: Monday 18. May 2020 at 14.39
To: Qt Project Development 
Subject: Re: [Development] Finishing the transition to the cherry-pick model

> On 15 May 2020, at 13:58, Volker Hilsheimer  wrote:
> The cherry-pick bot that processes Pick-to footers in commits will be turned 
> on in the remaining module repositories [1] on Monday.
>
> Changes in dev that have the Pick-to: footer already today will be 
> cherry-picked and pushed into the respective branches by your’s truly early 
> next week; some of those will have conflicts, you will be notified if you 
> authored the original change. Those that don’t have conflicts will be 
> approved and staged; if they break in CI, you will also be notified.


Hi,

Cherry-pick bot is now turned on in all repositories. Thanks Daniel!

I’ve generated cherry-pick commits for all changes in dev that have the 
Pick-to: footer, and I’m in the process of pushing those to gerrit with topic 
“pre-cherry-pick-bot”.

https://codereview.qt-project.org/q/topic:pre-cherry-pick-bot

Changes that were already on gerrit, but had been abandoned or are deferred, 
are taken out of the pushed chain of commits.

The output attached lists the result for each commit that was picked. Commits 
for which the script generated a warning or error (look for yellow or red lines 
in the attachment) might need attention. I’ll +2 and stage cherry-picks that 
didn’t cause problems once I’m done, but I’m not going to be upset with anyone 
that does it either.

Should there be any commits missing, please go ahead and cherry-pick those 
manually, or using the gerrit UI. wiki.qt.io is updated with instructions:

https://wiki.qt.io/Branch_Guidelines


Cheers,
Volker



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] Qt 5.15.0 Beta4 released

[Tuukka Turunen]

Hi,

I would like encourage everyone to test with the Beta 4 as much as possible, 
not to wait for RC.

After the final downmerge to 5.15.0 only fixes to clear blockers should go in, 
others go into Qt 5.15.1 patch release. 

Yours,

Tuukka

On 20.4.2020, 15.17, "Releasing on behalf of Jani Heikkinen" 
 wrote:

Hi,

We have released Qt 5.15.0 Beta4 today. Delta to beta3 attached

As earlier you can find Beta4 from Qt Online Installer, under 'Preview' 
category (and node).

Target is to release Qt 5.15.0 RC at the end of April so please make sure 
all release blockers are visible in the blocker list 
(https://bugreports.qt.io/issues/?filter=21925) immediately.

br,
Jani Heikkinen
Release Manager


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Finishing the transition to the cherry-pick model

[Tuukka Turunen]

Hi,

Since there is no plan to make further Qt 5.14.x patch release, I think the 
simplest is still to close and focus the bug fixes to dev (and cherry pick to 
5.15) or 5.15.0 in case needed in that release.

But as said, I am fine with whatever works best - also from the viewpoint of 
avoiding unnecessary merges needed before getting Qt 5.15.0 released. 

Yours,

Tuukka

On 20.4.2020, 10.59, "Shawn Rutledge"  wrote:



> On 20 Apr 2020, at 07:59, Tuukka Turunen  wrote:
> 
> 
> Hi,
> 
> +1
> 
> I would also close Qt 5.14 branch already now.
> 
> The other option is that some fixes pushed into Qt 5.14 branch at the 
time of Qt 5.15 RC1 only land in Qt 5.15.1.
> 
> Neither of these is problematic to me, assuming that the change that may 
be landing to 5.14 in the last minute is not a as such a blocker for Qt 5.15 
release.

It might be best to wait until after Bug Fix Week (this week) and merge 
those fixes from 5.14->5.15 though.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Finishing the transition to the cherry-pick model

[Tuukka Turunen]

Hi,

+1

I would also close Qt 5.14 branch already now.

The other option is that some fixes pushed into Qt 5.14 branch at the time of 
Qt 5.15 RC1 only land in Qt 5.15.1.

Neither of these is problematic to me, assuming that the change that may be 
landing to 5.14 in the last minute is not a as such a blocker for Qt 5.15 
release.

Yours,

Tuukka

On 20.4.2020, 8.28, "Development on behalf of Jani Heikkinen" 
 wrote:

> -Original Message-
> From: Development  On Behalf Of
> Volker Hilsheimer
> Sent: lauantai 18. huhtikuuta 2020 12.22
> To: Thiago Macieira 
> Cc: development@qt-project.org
> Subject: Re: [Development] Finishing the transition to the cherry-pick 
model
> 
> > On 18 Apr 2020, at 02:50, Thiago Macieira 
> wrote:
> >
> > On Friday, 17 April 2020 10:31:04 -03 Volker Hilsheimer wrote:
> >>> Please disable merging only after 5.14 branch is closed, so all
> >>> changes to it  make it into 5.15.0.
> >>>
> >>> The 5.14 branch closes the moment 5.15.0-rc1 is out.
> >>
> >> To clarify, we don’t “disable merging”, we turn off the bot. People
> >> with the privilege to push merge commits can in theory continue to do 
so
> forever.
> >
> >> Merging 5.14 into 5.15 fully before the RC will be part of the manual
> >> merge process.
> >
> > Ok, so can we close the 5.14 branch before we change to cherry-pick
> > mode? That will only leave 5.15 to dev, which we can coordinate.
> 
> Yes, that’s the intention.
> 

Yeah. If we want to get all changes from '5.14' to Qt 5.15.0 we has to 
close it before RC & also do the final merge from '5.14' to '5.15.0' before it. 
Because we aren't planning to do new releases from '5.14' should we just remove 
staging option from '5.14' already now to be able to do final merge from '5.14' 
to '5.15' before final downmerge to '5.15.0'? I think we should.

br,
Jani

___
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

Re: [Development] [Releasing] Meeting minutes from Qt Release Team meeting 31.3.2020

[Tuukka Turunen]

Hi,

I would like to take this opportunity to thank our release team as well as all 
others developing Qt. 

By nature our community is distributed, but typically the developers of The Qt 
Company are working from an office. However, for the past weeks we all have 
been working almost completely from home. This sets some additional challenges 
to things such as automated testing, but we have been able to proceed really 
well. 

Being able to create full releases successfully in situation like this is a 
great achievement.

So big thank you to all who have been helping to make it happen.

Yours,

Tuukka

On 31.3.2020, 17.27, "Releasing on behalf of Jani Heikkinen" 
 wrote:

Meeting minutes from Qt Release Team meeting Tue 31st March 2020

Qt 5.14.2:
- Released today. No official announcement yet because verification from 
production is stuck at the moment
   * Official announcement will happen after needed verifications are done

Qt 5.12.8 status:
- We should have release content in place finally and qt5.git integration 
ongoing.
- Target is to create release packages tomorrow, run RTA once again and 
release Qt 5.12.8 later this week if everything is still OK

Qt 5.15.0 status:
- Target is to create beta3 at the end of this week
   * qt5.git integration is ongoing
- String Freeze will be in effect Wed 1st April, see 
https://lists.qt-project.org/pipermail/localization/2020-March/000381.html
- API review still ongoing: Same reviews as last week are still ongoing 
(qtbase API review + plugins.qmltypes updates for qt3D and qtquickcontrols2)
- Plan forward is:
   * Beta3 ~beginning of April
   * Beta4 ~mid April
   * RC at the end of April
   * Final ~mid May
   ** Release blocker list here: 
https://bugreports.qt.io/issues/?filter=21925

Next meeting Tue 7th April 2020 16:00 CET

Br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:47]  akseli: iieklund: thiago: lars: frkleint: 
vladimir-m: ankokko: mapaaso:carewolf: fregl: ablasche: ping
[17:02:17]  jaheikki3: pong
[17:02:32]  jaheikki3: pong
[17:02:47]  Time to start qt release team meeting
[17:03:02]  On agenda today:
[17:03:06]  Qt 5.14.2 status
[17:03:11]  Qt 5.12.8 status
[17:03:15]  Qt 5.15 status
[17:03:23]  Any additional item to the agenda?
[17:06:27]  Let's start from Qt 5.14.2 status
[17:06:42]  Qt 5.14.2 is actually released
[17:07:08]  But no official announcement yet because 
verification from production is blocked
[17:07:56]  It seems downloading from download.qt.io isn't 
possible atm
[17:08:27]  Official announcement & blog post will be published 
when we are able to do needed verifications
[17:08:52]  Hoping all that can happen tomorrow morning
[17:09:12]  That's all about Qt 5.14.2. Any comments or 
questions?
[17:11:25]  Ok, then Qt 5.12.8 status:
[17:11:48]  We should have release content in place finally
[17:12:01]  And qt5.git integration is just started
[17:12:29]  Target is to create release packages tomorrow
[17:12:38]  Then run RTA for those packages
[17:12:59]  And if all OK release Qt 5.12.8 later this week
[17:13:09]  That's all about Qt 5.12.8
[17:13:16]  Any comments or questions?
[17:15:13]  And finally Qt 5.15 status
[17:15:43]  Target is to release beta3 at the end of this week
[17:16:19]  qt5.git integration ongoing and after it succeed we 
will start creating beta3 packages
[17:16:36]  Qt 5.15 String Freeze will be in effect Wed 1st 
April, see 
https://lists.qt-project.org/pipermail/localization/2020-March/000381.html
[17:16:58]  API review still ongoing: Same reviews as last week 
are still ongoing (qtbase API review + plugins.qmltypes updates for qt3D and 
qtquickcontrols2)
[17:17:22]  - Plan forward is:
[17:17:32]  Beta3 during this week
[17:17:41]  Beta4 ~ Mid april
[17:17:52]  RC at the end of April
[17:18:13]  And Qt 5.15.0 final release ~ mid May
[17:18:33]  Qt 5.15.0 release blocker list here: 
https://bugreports.qt.io/issues/?filter=21925
[17:18:54]  That's all about Qt 5.15 status at this time. Any 
comments or questions
[17:19:22]  jaheikki3: This Qt Designer webengineplugin 
thing should be  a blocker
[17:20:24]   QTBUG-82527
[17:20:46]  done..well, hopefully
[17:21:41]  Yeah, hopin so
[17:22:10]  ok, then we should be all set..
[17:22:35]  Ok, it was all at this time.
[17:23:04]  Let's end this meetin now and have new one Tue 7th 
April at this same time
[17:23:19]  Thanks for your participation, bye!
___
Releasing mailing list
releas...@qt-project.org
https://lists.qt-project.org/listinfo/releasing


___
Development mailing list
Development@qt-project.org

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Tuukka Turunen]

Great! Hopefully the remaining steps towards alpha go nicely. 

There are quite a few items not yet listed at: 
https://wiki.qt.io/New_Features_in_Qt_5.15 

The new feature highlight is valuable for users, so please lift a few of the 
key items for each module into the list. Think what are the most important 
items to tell our users.

We should have more content in place before the alpha, and finalize this before 
the first beta release. 

Yours,

Tuukka

On 11.2.2020, 11.12, "Development on behalf of Volker Hilsheimer" 
 wrote:

> On 10 Feb 2020, at 13:44, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> It seems that there is still some work needed to finalize deprecations 
and replacement for Qt 5.15
> 
> We had some discussion here in Qt Company and based on that I propose:
> 
> - Let's put Alpha out after this header view feature is in.


HeaderView change merged this morning:

https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170

so we should be good to go with the Alpha.

Cheers,
Volker



> - Let's agree these deprecations can be done still even the FF is in 
effect. But let's try to finalize deprecations and replacements as soon as 
possible.  Blocking Alpha until all these are in doesn't make sense at this 
point anymore.
> - Before Beta1 these deprecations needs approval of module maintainer
> - And after Beta1 adding new deprecations needs Lars's approval
> 
> That should bring us enough flexibility in this special situation without 
compromising or risking the Qt 5.15 release schedule too much.
> 
> br,
> jani
> 
> 
> 
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> Jani Heikkinen
>> Sent: torstai 6. helmikuuta 2020 10.03
>> To: Mitch Curtis ; Lars Knoll ; 
Yulong
>> Bai 
>> Cc: Qt development mailing list ;
>> releas...@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze 
is
>> in effect now
>> 
>>> -Original Message-
>>> From: Mitch Curtis 
>>> Sent: keskiviikko 5. helmikuuta 2020 15.40
>>> To: Jani Heikkinen ; Lars Knoll
>>> ; Yulong Bai 
>>> Cc: Volker Hilsheimer ; Qt development
>>> mailing list ; releas...@qt-project.org
>>> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature
>>> Freeze is in effect now
>>> 
>>> 
>>> Hi Jani.
>>> 
>>> - It's a vital part of creating a table in Qt Quick, and something
>>> that is non- trivial for a good chunk of users to implement themselves.
>>> - I think you and Lars have already said it's low risk, which is true.
>>> - I don't think this counts as justification, but.. it's been in the
>>> works for a while, and we really shouldn't delay it any longer.
>>> - I'm also confident we will be ready to merge it today.
>> 
>> Hi,
>> 
>> Ok, nice to hear it won't take that long to get this in. And based on all
>> discussion related to this & qt5.15 overall let's take this in Qt 5.15.
>> 
>> We have other issues delaying alpha packages as well so this won't be 
only
>> thing delaying it  Let's try to finalize alpha content during this week 
& get
>> Alpha out during next one
>> 
>> Br,
>> Jani
>> 
>> 
>> ___
>> 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

___
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

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Tuukka Turunen]

Hi,

In practice we also do have some slack in the schedule exactly to allow sorting 
everything out. Unfortunately it is often not long enough, but we have delay in 
getting the alpha out. I do agree that we should include the features that are 
ready in time - and I do not think there are many who would disagree. 

One thing that tends to happen is the last minute pile up of commits at or near 
the FF time. While understandable, the more we can do to avoid this the more 
likely it is to have successful integrations. 

Especially with Qt 6 we need to make sure as many items as possible are not 
piling up just at the FF date. Maybe we should set a bit earlier FF date for 
the modules most others depend upon? Or other similar phasing instead of a day 
when everything needs to be in. 

Yours,

Tuukka
 

On 7.2.2020, 9.59, "Releasing on behalf of Eskil Abrahamsen Blomfeldt" 
 wrote:


On 05.02.2020 13:04, Jani Heikkinen wrote:
>
>> -Original Message-
>> From: Eskil Abrahamsen Blomfeldt 
>> Sent: keskiviikko 5. helmikuuta 2020 13.06
>> To: Edward Welbourne ; Jani Heikkinen
>> ; Lars Knoll ; Volker Hilsheimer
>> 
>> Cc: Qt development mailing list ;
>> releas...@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze 
is
>> in effect now
>>
>>
>> On 05.02.2020 11:50, Edward Welbourne wrote:
>>> Jani Heikkinen (5 February 2020 06:42)
 Why this is so important that we should get the exception & go in after
>> FF?
>>> Do we allow changes approved before feature freeze to get past the
>>> Coin hurdle, even if that happens after FF ?  How much fixing of the
>>> change (if it turns out to have problems integrating) is acceptable,
>>> before we declare that it's no longer the change that was approved in 
time
>> ?
>>
>>
>> If the change is ready and approved by the time of feature freeze and 
only
>> delayed by CI problems, failures from other changes in a batch, or the
>> awkwardness of our dependency structure, I think it has to be acceptable 
to
>> merge after the freeze. Otherwise feature freeze becomes a lottery where
>> the features in a given release is based mostly on chance.
> By default we shouldn't put any new features in after FF, not even those 
which were approved early enough. Not respecting the freeze date was one of 
biggest reasons why we failed to keep the release schedule with earlier 
releases. And after we started to be much tighter with the freeze we have been 
much better to keep the schedules as well...

Hi,

You are looking at this from a very different perspective than me, which 
is totally understandable.

As a developer of the product, I want a deadline for when I should have 
my feature finished. If the deadline is "maybe one month before the 
feature freeze, maybe one week, who knows it kind of depends on whether 
the CI system is acting up and what other changes your fix happens to be 
bundled with", then that makes it impossible to plan anything.

If we estimate, based on statistics, that it will take one month to get 
features in, then we should set the feature freeze one month earlier. If 
we think it will take one week, then we should set it one week earlier. 
At least we should give people a specific date and guarantee that if 
they make it in time for this, their change will be in the next release. 
If this is one month before the actual feature freeze, then so be it. If 
it takes that long to get a change in, then definitely should be very 
visible to everyone, including the stake-holders who depend on features 
being released when we say.

If it turns out that we miscalculated the estimate, then this should 
just cause a delay to the release. It shouldn't cause us to make a 
release containing a random set of features based on whoever won the 
lottery this time.

I understand that your responsibility is making the release on time, and 
late submissions make this difficult, but the way to solve this is to 
add the extra slack between the feature freeze and the point where we 
can start stabilizing to the release schedule. If we see that changes 
that are staged at the freeze date consistently take between 1 day and 1 
week to merge because we have broken systems or because so many people 
stage their changes at the same time, then that means we have to extend 
the period between freeze and release by one week.


> We are doing time based releases so if new feature misses the deadline 
> there will be next one coming after few months. It might be quite long 
> time for unique feature but on the other hand it isn't really that 
> long... Our goal is to cut the schedule between FF and final release, 
> not reserving more time there. Ok, 

Re: [Development] (no subject)

[Tuukka Turunen]

Hi Emily and Jenifer,

If you wish be removed from the mailing list, you can unsubscribe via: 
https://lists.qt-project.org 

Do not send requests asking to be removed from the list, just unsubscribe 
following the instructions online.

Yours,

Tuukka

On 31.1.2020, 15.29, "Development on behalf of Jenifer Lambert" 
 wrote:

Take me off this list

Sent from my iPhone

> On Jan 31, 2020, at 5:02 AM, Emily Kaizer  wrote:
> 
> Take me off this list 
> 
> Sent from my iPhone
> ___
> 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


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Forgot your Qt Account password?

[Tuukka Turunen]

Hi,

Someone apparently created a Qt Account for the 
development@qt-project.org mailing list.

Good idea, but we do want the accounts to be individual.

Yours,

Tuukka

From: Development  on behalf of Qt Project 
Development 
Reply-To: Khuram Ali 
Date: Wednesday 29. January 2020 at 16.09
To: Qt Account Support , Qt Project Development 

Subject: Re: [Development] Forgot your Qt Account password?

Hi,

I haven't requested to reset my Qt Account password. It seems some malicious 
attempt. Please advise. thank you!

Regards,
Khuram Ali

-Original Message-
From: The Qt Company 
To: development 
Sent: Wed, Jan 29, 2020 3:04 pm
Subject: [Development] Forgot your Qt Account password?
Hi,

We just received a request to reset the password for your Qt Account.

No worries, you can simply make a new one. Just use the link below within 24 
hours.

https://login.qt.io/reset/w2ntQNBn2UMl6FuTRRi0aZsZoouN9r32

If you did not make this request, you can ignore this notification. You are 
welcome to reply to this email to report login issues or share any feedback you 
might have.

Best regards,

The Qt Account Team

---
The Qt Company
qtacco...@qt.io
https://qt.io/ | https://blog.qt.io/ | https://twitter.com/qtproject | 
http://www.youtube.com/qtstudios | https://www.facebook.com/qt
___
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

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

Hi Alberto,

No, that is not the plan. For open-source user all releases are to be similar. 
New patch releases come until the next feature release is out. For commercial 
license holders, there will be additional patch releases available for selected 
Qt versions (Qt 5.15, Qt 6.2, ...)

Yours,

Tuukka

On 29.1.2020, 13.35, "Development on behalf of Alberto Mardegan" 
 
wrote:

On 29/01/20 13:02, Edward Welbourne wrote:
> Clarification: we'll be moving to "all commits land first on dev and are
> cherry-picked out to other branches that need them" in place of our
> present merge-based module.  Where Cristián says "all those patches will
> be on Gerrit", they'll be on dev on Gerrit.  They'll be cherry-picked
> from there to a (presumably) private branch (maybe on a private repo),
> so you won't necessarily see the cherry-picked versions, only the dev
> versions.  So any time the cherry-pick requires adaptation to the LTS,
> those running the fork above would need to duplicate the adaptation.

Do I understand correctly that LTS releases will not have point
releases, while non-LTS releases (like, currently we have 5.13.2 and
5.14.1) will continue to have them?

Ciao,
  Alberto

-- 
http://www.mardy.it - Geek in un lingua international
___
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

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

" will the owners of a commercial license be given access to the branch? "

=> Yes. 

Yours,

Tuukka

On 29.1.2020, 13.21, "Giuseppe D'Angelo via Development" 
 wrote:

Hi,

Il 29/01/20 11:02, Edward Welbourne ha scritto:
> They'll be cherry-picked
> from there to a (presumably) private branch (maybe on a private repo),
> so you won't necessarily see the cherry-picked versions, only the dev
> versions.  So any time the cherry-pick requires adaptation to the LTS,
> those running the fork above would need to duplicate the adaptation.

Thanks for the further clarifications. There's still plenty of 
uncertainty in the above message, though (presumably, maybe, 
necessarily), when are we going to know more about these details?
Ultimately, it boils down to: will the 5.15 branch become private or not?

On a similar issue: will the owners of a commercial license be given 
access to the branch? (Will it become TQC private, or TQC+commercial 
private?). The point being, will the commercial licensees know exactly 
which patches (already landed on dev) have been cherry picked and when 
(which release contains a given patch)?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

Hi Antonio,

Like the announcement says: "Starting with Qt 5.15, long term support (LTS) 
will only be available to commercial customers." There is no plan currently to 
change ongoing Qt 5.9 LTS or Qt 5.12 LTS support period. 

Qt 5.12 is currently in Strict phase, next step moving to Very strict phase 
according to: https://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst 

During the Strict phase Qt 5.12 will receive some of the most important bug 
fixes, but not all. We do not want to cause instability and every change is 
prone to do that.

During the Very strict phase (last year) Qt 5.12 is to receive security fixes 
only - and possibly some bug fix, although at that point there really should no 
more be such bugs that should be fixed.

Note that the release cadence will be much slower towards the end of the LTS 
life-cycle - just like with Qt 5.9 LTS. 

Yours,

Tuukka

On 29.1.2020, 13.05, "Development on behalf of Antonio Larrosa" 
 wrote:

On 27/1/20 15:34, Lars Knoll wrote:
> One is a change in policy regarding the LTS releases, where the LTS part 
of a release is in the future going to be restricted to commercial customers. 
All bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
Backporting bug fixes is something that the Qt Company will take care of for 
these LTS branches. We’ve seen over the past that LTS support is something 
mainly required by large companies, and should hopefully help us get some more 
commercial support for developing Qt further.
> 

With everyone talking about how long will fixes for Qt 5.15 be provided to 
open
source developers (and the common consensus being they'll be available only
around 6 months until ~Jan 2021) I have a question about 5.12.

When Qt 5.12 was released the promise back then was it will be maintained 
until
5/12/2021 . Is that still true? or will 5.12 not get public maintenance 
once Qt
6.0 is released just as 5.15?

I find it hard to believe The Qt Company will break already made "contracts"
with the community about LTS life-cycles of released products, but in that
scenario we have a bit of a paradox with 5.12 LTS being maintained for 
longer
than 5.15 LTS so it would be nice to get some clarification on that.

Also, I have a question in order to clarify the announcement. Which of the 
next
sentences is true?

1) Once Qt 6.0 is released, there won't be Qt 5.15.x public releases 
anymore and
Qt developers from The Qt Company will work in a closed branch/git 
repository
which will only get released to commercial customers.

2) Once Qt 6.0 is released, there won't be Qt 5.15.x public releases 
anymore but
backported fixes will be accessible at the 5.15 branch of the git 
repository as
usual.

I guess the answer is 1), but the blog announcement always talks about 
releases,
which is left to interpretation. So I hope The Qt Company reconsiders and 
takes
at least the 2) option approach as a way to make the announcement a bit 
less bad.

--
Antonio Larrosa
___
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

Re: [Development] QtPDF did not change license

[Tuukka Turunen]

Hi,

Correct. Qt PDF license has not been changed. 

Some of the contributors preferred to keep the license as LGPL. When we were 
checking this, some info did not get through. So while the change to GPL would 
be completely fine for many, there was still concerns and pushback towards 
changing the license. 

In general changing a license is always challenging, and to the extent possible 
we try to get all key contributors on board if such is considered. For Qt PDF 
it would have been better to start off with GPL from the very beginning, but we 
did not do that when the Qt PDF was first created by The Qt Company.

Yours,

Tuukka

On 28.1.2020, 22.45, "Development on behalf of Jason H" 
 wrote:

/r/ThereWasAnAttempt

> Sent: Tuesday, January 28, 2020 at 12:53 PM
> From: "Giuseppe D'Angelo via Development" 
> To: development@qt-project.org
> Subject: [Development] QtPDF did not change license
>
> Il 28/01/20 18:37, Jason H ha scritto:
> > - the previous license changes Tukka announced (QtPDF, 
etc:https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf)
>
> As per subject. The blog post is inaccurate.
>
> > https://lists.qt-project.org/pipermail/interest/2019-October/033979.html
>
>
> My call here went unanswered.
>
> > https://lists.qt-project.org/pipermail/interest/2019-October/034045.html
>
> My 2 c,
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> 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


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

Hi,

I do not know why the link does not work. But I remember that post very well.

On hindsight, it was too much of a rush back then to ask everyone to create a 
Qt account immediately.

As I wrote in my earlier reply, situation is different now:

  *   Most users have already Qt account
  *   Marketplace needs it
  *   More common to be connected

If someone does not want to use Qt account, it is possible to build from source.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Giuseppe 
D'Angelo via Development  puolesta
Lähetetty: maanantaina, tammikuuta 27, 2020 8:13 ip.
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Changes to Qt offering

Il 27/01/20 16:57, Benjamin TERRIER ha scritto:
We do hope that this eases your concerns, and that we can continue with your 
trust.


https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer


That blog post is now removed. The URL is correct, as it's cross referenced 
from other blog posts.

I won't comment on how professional this sounds.

Anyhow:

https://web.archive.org/web/20200127170008/https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer


--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com 
| Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

Hi,

Well, quite many things have changed since 2015. One important item is that 
almost one million users have already voluntarily created (and verified) 
themselves a Qt account.

See the FAQ (linked from the blog post):

“Q: Will requiring the Qt Account drive away all Qt users?
A: We have had the Qt Account as an option for over 4 years, and during that 
time there has been already nearly a million people who have registered and 
verified their Qt Account. It is obvious that that in the world that we live 
today having an account for a service is not a blocker for people in general. 
Everyone has the option of building Qt from sources if they do not like the 
installer, but we believe that we provide value to our users through the 
installer and the Qt Marketplace to justify the Qt Account.“

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Benjamin 
TERRIER  puolesta
Lähetetty: maanantaina, tammikuuta 27, 2020 6:03 ip.
Vastaanottaja: Qt development mailing list
Aihe: Re: [Development] Changes to Qt offering

Quoting The Qt Company itslef:

Thanks for your feedback to the new online installer asking for a Qt Account 
signup. We have evaluated the feedback received via the blog,
various discussion forums, irc and other channels. Based on all these comments 
and discussions with our partners we realize that this was not our finest 
moment.
Preventing the growth and usage of Qt in the open source community is not what 
we want to happen. We did already see a nice jump in the number of Qt Accounts,
but it was never our intention to make our valued community and contributors 
upset with us or stop using and contributing to Qt.
We clearly ill-calculated how asking for a Qt Account with the online installer 
would make our users feel. A mistake. Sincere apologies.
[...]
We do hope that this eases your concerns, and that we can continue with your 
trust.


https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer

 So apparently the trust of the QT community os nt a concern anymore...

Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
mailto:enmarantis...@gmail.com>> a écrit :
I am afraid I do not have other words for this model than : absolutely 
disgusting and a complete dick move. Especially login requirement for binaries.
I don't even understand how distros are now supposed to keep qt code safe since 
constantly pushing qt version up is recipe for problems and there will be no 
critical bugfixes to branches that distros were stabilized at.


On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:
Hi all,

The Qt Company has done some adjustments to the Qt will be offered in the 
future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .

The change consists of three parts.

One is a change in policy regarding the LTS releases, where the LTS part of a 
release is in the future going to be restricted to commercial customers. All 
bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
Backporting bug fixes is something that the Qt Company will take care of for 
these LTS branches. We’ve seen over the past that LTS support is something 
mainly required by large companies, and should hopefully help us get some more 
commercial support for developing Qt further.

The second change is that a Qt Account will be in the future required for 
binary packages. Source code will continue to be available as currently. This 
will simplify distribution and integration with the Marketplace. In addition, 
we want open source users to contribute to Qt or the Qt ecosystem. Doing so is 
only possible with a valid Qt Account (Jira, code review and the forums all 
require a Qt Account).

The third change is that The Qt Company will in the future also offer a lower 
priced product for small businesses. That small business product is btw not 
limited to mobile like the one Digia had some years ago, but covers all of Qt 
for Device Creation.

None of these changes should affect how Qt is being developed. There won’t be 
any changes to Open Governance or the open development model.

Best regards,
Lars

___
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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

Hi,

In essence the LTS patch release is a selection of bug fixes and security fixes 
(including update of 3rd party libraries). The bug fixes and security fixes 
will go first to dev and are cherry picked back to release branches.

After the change every release of Qt will look like a non-lts release for 
open-source users. Think of Qt 5.14 as an example. It was released in December. 
Today it received the first patch release. There will be more before next 
feature release is out. For open-source user Qt 5.15 will look just like Qt 
5.14 does.

For commercial license holders the patch releases of Qt 5.15 keep rolling just 
like Qt 5.9. This is expected to convince some of the companies using Qt 
open-source to select the paid version. Not every company, but hopefully many 
enough.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Ville 
Voutilainen  puolesta
Lähetetty: Monday, January 27, 2020 5:45:32 PM
Vastaanottaja: NIkolai Marchenko 
Kopio: Qt development mailing list 
Aihe: Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 17:36, NIkolai Marchenko  wrote:
>
> >  I expect security fixes
> but that's basically what an LTS is ... isn't it?

An LTS gets rather more than just security fixes; an example of that
is compiler compatibility fixes.
Some of us, including Qt employees, backport bug fixes that are not
actual new features to LTS branches
regularly.
___
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

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

Hi,

The criteria to qualify for the small business / startup is:
-  Revenue or funding less than 100.000 USD annually
- Max 5 employees

Yours,

Tuukka

On 27.1.2020, 16.58, "drwho"  wrote:

On 2020-01-27 9:34 a.m., Lars Knoll wrote:
> The third change is that The Qt Company will in the future also offer a 
lower priced product for small businesses. That small business product is btw 
not limited to mobile like the one Digia had some years ago, but covers all of 
Qt for Device Creation.

Has it been specified what defines a small business, 100K yearly profit?

It would be nice to have a licensing option for binaries only, no 
support.  The company I work for is moving all our Qt5.6 console apps to 
GoLang because we can't afford the cost for 5 seats and the 40,000 units 
per year device royalty.  The 5 seat cost would be almost 10% of our 
software budget.  Go and Rust are free.  It is hard justify a Qt 
commercial license for console only apps.

Jon

___
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

Re: [Development] Changes to Qt offering

[Tuukka Turunen]

Hi Ekke,

Currently Qt MQTT is not part of Qt for Device Creator or Application 
Development product, see: https://www.qt.io/features 

Huge amount of other libraries are included, but unfortunately MQTT is only 
available as part of the Qt for Automation. 

Yours,

Tuukka

On 27.1.2020, 16.47, "Development on behalf of ekke" 
 wrote:

Am 27.01.20 um 15:34 schrieb Lars Knoll:
> ...
>
> The third change is that The Qt Company will in the future also offer a 
lower priced product for small businesses. That small business product is btw 
not limited to mobile like the one Digia had some years ago, but covers all of 
Qt for Device Creation.

sounds great

would this per ex enable mobile apps to integrate MQTT ?

ciao

ekke

___
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

Re: [Development] Contributing to Qt session at Qt World Summit

[Tuukka Turunen]

Hi,

Unfortunately no recording. We had the session in the hack space, not part of 
the technical tracs (that were recorded and will be available later).

Yours,

Tuukka

On 07/11/2019, 13.20, "Paul Wicking"  wrote:

This sounds great! Was the session recorded, and if so is it viewable 
somewhere online, for people that weren't there?

P.

On 07/11/2019, 07:58, "Development on behalf of Tuukka Turunen" 
 wrote:

 
Hi,
 
Yesterday morning at the Qt World Summit we had a session about 
contributing to Qt. I was really happy to see over 80 people joining the 
session at 8 am before the second day keynotes (and after
 a great party the previous evening). We actually run out of chairs in 
the room we had booked for this, so quite many had to stand.

 
We discussed about the various ways of contributing (also other than 
source code), showed hands-on how a code contribution is done, and had a panel 
discussion about contributing to Qt. Hopefully
 we encouraged new contributors. 
 
Yours,
 
Tuukka
 
 
 





___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Contributing to Qt session at Qt World Summit

[Tuukka Turunen]

Hi,

Yesterday morning at the Qt World Summit we had a session about contributing to 
Qt. I was really happy to see over 80 people joining the session at 8 am before 
the second day keynotes (and after a great party the previous evening). We 
actually run out of chairs in the room we had booked for this, so quite many 
had to stand.

We discussed about the various ways of contributing (also other than source 
code), showed hands-on how a code contribution is done, and had a panel 
discussion about contributing to Qt. Hopefully we encouraged new contributors.

Yours,

Tuukka



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Contributors' Summit 2019 - Registration open!

[Tuukka Turunen]

Hello everyone,

We have now close to 80 persons registered to the Qt Contributor's Summit. If 
you are planning to attend, but have not registered yet, please do so now. 
Latest by 25th October we need to have the registrations in to take care of all 
the practicalities without a rush.

The program at https://wiki.qt.io/Qt_Contributors_Summit_2019_Program is nicely 
shaping up. Please update your sessions as soon as you have it ready. Remember 
to add the session description as well. 

Note that it is possible to have longer sessions as well - for example working 
on some topic for half a day or so. The sessions of days 2 and 3 are indented 
to be mainly working sessions or at least active discussion - most of the 
information sharing ("lecture type") sessions we are aiming to have on day 1.

Yours,

Tuukka

On 18/09/2019, 17.45, "Development on behalf of Kai Köhne" 
 wrote:

Hi,

Registration to the Qt Contributors Summit 2019 (Nov 19-21th) is now open!

https://www.surveymonkey.com/r/RNN7NXP

The event is open to anyone who has contributed to Qt. It is free of 
charge, but requires registration so that we can do some planning. There's also 
a maximum amount of people we can accommodate, so it's best to register as soon 
as you have made plans!

You can find more about the event at

  https://wiki.qt.io/Qt_Contributors_Summit_2019

We'll continue to update the wiki, especially the program page: 
https://wiki.qt.io/Qt_Contributors_Summit_2019_Program

Regards

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

___
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

[Development] Change in open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF

[Tuukka Turunen]

Hi,

Open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt 
PDF is to be changed from LGPLv3/Commercial to GPLv3/Commercial. Change becomes 
in effect with Qt 5.14 release. Going forward, these modules are no longer 
available under LGPLv3 license option. The key rationale for this is to 
increase the amount of GPLv3/Commercial licensed Qt add-ons. Blog post 
announcement of this is at: 
https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf

Qt Wayland Compositor and Application Manager are mainly used in complex multi 
process embedded systems. The Wayland Compositor is a special purpose module 
and is not used on desktop and mobile platforms. The module does require 
significant ongoing investments and licensing it under GPLv3 will help cover 
those expenses. The Application Manager is using the Wayland Compositor. It is 
currently not part of Qt and only available through the Automotive Suite, but 
being developed on qt-project.org<http://qt-project.org/>. Qt PDF is a new 
module, which has not been released earlier despite the pre-release code being 
available. Changing the license to GPLv3 will allow The Qt Company to support 
the module going forward.

Since January 2016 many of the completely new Qt add-on modules developed by 
The Qt Company have been licensed under GPLv3 license for open-source users in 
addition to the commercial licensing option. We use GPLv3 license for the 
selected Qt Add-Ons in order for those making closed-source applications or 
devices to pick the commercial option when using these add-on modules, while 
still providing the functionality under an open-source license for open-source 
applications.

In addition to developers from The Qt Company, the main contributors of these 
modules are from Luxoft and KDAB. We have discussed the license change 
beforehand with both of them and they accept making this license change.

The change in licensing of Qt Wayland Compositor, Qt Application Manager and Qt 
PDF is implemented in the coming days to be in effect by Qt 5.14 release 
timeframe and later releases.

Yours,

    Tuukka Turunen
The Qt Company




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Tuukka Turunen]

Hi,

Documentation is the authorative source. It is maintained and checked for each 
Qt release. We should make sure the platform notes are correct and complete. 
Misleading information in wiki should be deleted or marked as deprecated. 
Similar activity has been done to other pages, sometimes we may even want to 
move items from the wiki to docs. It is fine to have wiki to support, but there 
is high risk of wiki content to become outdated.

Yours,

Tuukka

On 20/09/2019, 12.03, "Development on behalf of Giuseppe D'Angelo via 
Development"  wrote:

Il 20/09/19 07:53, Tuukka Turunen ha scritto:
> Or remove the wiki entry and make sure platform notes in documentation 
are in shape?
> 
> No need for duplicated info on these basic items.

It's a bigger problem -- the *same* wiki is used for official 
information (e.g. releasing info; coding guidelines; security policies) 
as well as for unofficial, community-driven content. Nobody knows the 
official status of any individual page just by looking at it.

So now there's information on the wiki AND in the docs about Qt on 
INTEGRITY, they both appear on Google search results, and of course 
they're in contradiction with each other (wiki says that Qt on INTEGRITY 
is community-driven, docs say it's officially supported; wiki does a 
shared build, docs say only static builds work).

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] INTEGRITY

[Tuukka Turunen]

Or remove the wiki entry and make sure platform notes in documentation are in 
shape? 

No need for duplicated info on these basic items. 

Yours,

Tuukka

On 19/09/2019, 23.52, "Development on behalf of Kai Pastor, DG0YT" 
 wrote:

Am 19.09.19 um 10:41 schrieb Mutz, Marc via Development:
>
> 1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
> 2. That maintainer should either find the missing linker flag, or file 
> a bug with Integrity
> 3. If there's a work-around (providing those missing functions in Qt, 
> e.g.), apply it, else
> 4. drop Integrity support (or update to a newer version) ASAP (for Qt 
> 5.15 if not 5.14).
>
5. Cleanup the wiki page: https://wiki.qt.io/INTEGRITY_Platform

___
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

Re: [Development] INTEGRITY

[Tuukka Turunen]

Hi Marc,

A lot of the Qt functionality works perfectly well on INTEGRITY. Even the 
advanced graphics such as Qt Quick, Qt 3D and Qt 3D Studio. I do not see it 
reasonable to claim that it is "so far behind all the other supported 
platforms, as well as its own claim of conformance, that the question must be 
asked why it's still supported". Like any RTOS platform, there are known 
restrictions in the functionality supported on INTEGRITY: 
https://doc.qt.io/qt-5/integrity.html. If there are additional restrictions, 
those should be added to the platform notes. There also may be work arounds 
needed for some items, as suggested. In case of issues with the OS or the 
compiler, it is also possible to report a bug to Green Hills. 

Yours,

Tuukka


On 19/09/2019, 12.21, "Development on behalf of Mutz, Marc via Development" 
 
wrote:

On 2019-09-19 10:56, Lars Knoll wrote:
>> 4. drop Integrity support (or update to a newer version) ASAP (for
>> Qt 5.15 if not 5.14).
> 
>  This is a bit black and white. You’re proposing to drop all of
> INTEGRITY because you’re not willing to work around things on that
> platform for one patch that is in principle a pure cleanup patch doing
> internal refactoring. It wouldn’t be too difficult (though maybe not
> very nice looking though) to keep the old code for INTEGRITY only.
> It’s been tested and we know it works.
> 
> We’ve been applying workarounds for missing support for some C++11
> features in other toolchains/compilers as well. We kept the Atomic
> implementations for MSVC around for exactly the same reasons.

That may work for the series of patches that implements QWaitCondition 
using std::condition_variable, which, indeed, is just a cleanup patch.

But it helps nothing with all the places where we use QWaitCondition in 
Qt implementation and would like to replace it with 
std::condition_variable + std::mutex, because, as I explained in an 
earlier mail, QWaitCondition is a condition_variabe_any and thus has 
inherently and unavoidably more overhead than condition_variable + 
mutex. There is no justification to add #ifdefs for all the places that 
QWaitCondition is used unconditionally now, so either we don't get the 
order-of-magnitude improvement on our main platform, Windows, or we need 
to introduce a private QtPrivate::condition_variable as an inline 
wrapper around condition_variable + mutex or, for Integrity, 
QWaitCondition + QMutex, which we need to replace once more with 
std::condition_variable + mutex if Integrity is fixed. Is it worth it, 
for a buggy platform that's in the process of being fixed? I'm not sure 
it would be...

In addition, as Peppe noticed, this is not the first time Integrity has 
shown up as a problematic platform, and it now is so far behind all the 
other supported platforms, as well as its own claim of conformance, that 
the question must be asked why it's still supported.

Thanks,
Marc
___
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

Re: [Development] Closing 5.13 branch after Qt 5.13.2 release?

[Tuukka Turunen]

Hi,

Target is to reduce the merge steps after no further patch releases planned for 
Qt 5.13. One option would be to agree that at certain point 5.13 goes into 
cherry pick mode, if not closed.  That can be reached also by having 5.14 as 
the stable branch after 5.13.2 is branched. 5.13 could be open even until Qt 
5.14.0 is released, but only receive cherry picked changes from 5.14 branch. 

Yours,

Tuukka

On 05/09/2019, 19.30, "Development on behalf of Thiago Macieira" 
 
wrote:

On Thursday, 5 September 2019 08:51:40 PDT Tuukka Turunen wrote:
> That is probably quite close to Qt 5.13.2 timing. If we release it in mid
> October we have about a month to Qt 5.14.0. Of course release team still
> can push cherrypicked fixes into 5.13 after closed. So in case of some
> crucial fix there is no problem.

I think we should keep it open, since the timing could allow for a 5.13.3. 
The 
schedule for 5.14 straddles the contributor summit, so there's a non-
negligible chance that it won't be out by the end of November.

Worst case is that we don't release it and 5.13 gets merged into 5.14.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
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

Re: [Development] Closing 5.13 branch after Qt 5.13.2 release?

[Tuukka Turunen]

Hi,

That is probably quite close to Qt 5.13.2 timing. If we release it in mid 
October we have about a month to Qt 5.14.0. Of course release team still can 
push cherrypicked fixes into 5.13 after closed. So in case of some crucial fix 
there is no problem.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Thiago 
Macieira  puolesta
Lähetetty: torstaina, syyskuuta 5, 2019 6:25 ip.
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Closing 5.13 branch after Qt 5.13.2 release?

On Thursday, 5 September 2019 01:45:16 PDT Tuukka Turunen wrote:
> I propose to close 5.13 branch after the Qt 5.13.2 patch release, and from
> then on 5.14 is the stable branch to receive all bug fixes.

We should close it a month before the 5.14.0 release, no sooner. Bugfixes are
important to those who are deploying 5.13.x.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
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

Re: [Development] Save the date: Qt Contributors Summit 2019 is 19th - 21st November in Berlin

[Tuukka Turunen]

Hi,

Yes. Some pause due to holidays in this. We are working on getting the 
registration open in the coming weeks as well as more details of the planned 
structure. In general it is indented to be quite similar to earlier years. But 
instead of prepared "lectures" we would like to have prepared topics to be 
worked on by multiple persons. So that it would be less sessions of a few 
persons talking while others listen. Then we are also thinking of having a bit 
more time than earlier to work on things hands-on, hence three days instead of 
two.  

Yours,

Tuukka

On 05/09/2019, 13.57, "Development on behalf of André Hartmann" 
 
wrote:

Hi Tuukka,

any update on this? Do you already have a location and maybe a rough plan?

Best regards,
André


> Hi Thiago,
> 
> I hope you and other contributors can attend despite the days being 
> middle of the week.
> 
> Yours,
> 
> Tuukka
> 
> 
> *Lähettäjä:* Development  käyttäjän 
> Thiago Macieira  puolesta
> *Lähetetty:* Saturday, July 6, 2019 3:21:23 AM
> *Vastaanottaja:* development@qt-project.org
> *Aihe:* Re: [Development] Save the date: Qt Contributors Summit 2019 is 
> 19th - 21st November in Berlin
> On Friday, 5 July 2019 09:13:52 -03 Tuukka Turunen wrote:
>> Save the date: Qt Contributors Summit 2019 is in Berlin at 19th – 21st
>> November 2019.
> 
> As I explained when I was asked if the dates are good: they are not. Those
> dates are the middle of a week. That means travel on Monday and on Friday.
> 
> That means I don't know if I can make it this year.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>Software Architect - Intel System Software Products
> 
> 
> 
> ___
> 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
> 


-- 
Dipl.-Ing. (FH) André Hartmann
Softwareentwicklung / Software Development

E-Mail: andre.hartm...@iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 
26996-21

iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim 
Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

News / Information
https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - 
Unified Control Software
https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep 
the price
https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM 
Detectors
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! 
Product catalog 2017 / 2018 released
https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with 
reversible polarity

Links
https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay 
connected!
https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE 
| Tutorials and more ...
https://www.twitter.com/iseg_hv iseg on TWITTER | please follow!
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg 
CATALOG | download product catalog as PDF
http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, 
firmware and more...

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren 
Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist nicht
gestattet.

This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient
(or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in 
this e-mail is strictly forbidden.
___
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

[Development] Closing 5.13 branch after Qt 5.13.2 release?

[Tuukka Turunen]

Hi,

Now that we have Qt 6 work on top of the regular items there is quite a lot of 
merges even with Qt 5.12 entering the Strict (cherry pick) mode. 

Another item we could do to reduce the amount of merges needed is to agree a 
bit shorter than usual life-cycle for Qt 5.13. 

I propose to close 5.13 branch after the Qt 5.13.2 patch release, and from then 
on 5.14 is the stable branch to receive all bug fixes.  

After comments in the mailing list, release team could discuss this and make 
the decision in one of their regular meetings.

Yours,

Tuukka




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Save the date: Qt Contributors Summit 2019 is 19th - 21st November in Berlin

[Tuukka Turunen]

Hi Thiago,

I hope you and other contributors can attend despite the days being middle of 
the week.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Thiago 
Macieira  puolesta
Lähetetty: Saturday, July 6, 2019 3:21:23 AM
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Save the date: Qt Contributors Summit 2019 is 19th - 
21st November in Berlin

On Friday, 5 July 2019 09:13:52 -03 Tuukka Turunen wrote:
> Save the date: Qt Contributors Summit 2019 is in Berlin at 19th – 21st
> November 2019.

As I explained when I was asked if the dates are good: they are not. Those
dates are the middle of a week. That means travel on Monday and on Friday.

That means I don't know if I can make it this year.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
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

[Development] Save the date: Qt Contributors Summit 2019 is 19th - 21st November in Berlin

[Tuukka Turunen]

Hi,

Save the date: Qt Contributors Summit 2019 is in Berlin at 19th – 21st November 
2019.

This year we want to arrange a three day event with the first day reserved for 
maintainers and approvers only. From the second day onwards we welcome all 
contributors, just like before.

There will also be a new “Contribute to Qt” session at Qt World Summit, during 
which we hope to get more people interested in contributing to Qt.

At this point you can mark down the dates and location. Registration and agenda 
are coming up later.

Yours,

Tuukka

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development