Re: [Development] Who is in charge of qt-project.org?

[Tuukka Turunen]

Hi Christian,

What comes to the mistake with the mailing list archive, we of course fix it. 
Meanwhile, use the workaround described by Andy: " It is there, but you have to 
go to http://lists.qt-project.org for now, it is being moved to a new server so 
at some point the https address will be back, but until then you need to use 
the http address."

What comes to the Qt Project, it is how Qt is developed - all the work done for 
Qt by The Qt Company is via the Qt Project. The website where this is best 
visible is: https://codereview.qt-project.org, also the mailing lists are with 
qt-project.org domain.

The reasons for not having a separate site for open-source Qt and commercial Qt 
are described quite well in this blog post from, 2014: 
http://blog.qt.io/blog/2014/08/06/defragmenting-qt-and-uniting-our-ecosystem/ 

The hosting foundation for Qt Project (a non-profit organization registered in 
Norway) is currently inoperable, costs of running the web servers, download 
systems etc of the Qt Project are paid directly by The Qt Company. 

Yours,

Tuukka

On 31/10/2018, 23.50, "Development on behalf of Christian Gagneraud" 
 wrote:

On Thu, 1 Nov 2018 at 05:28, Kain Vampire via Development
 wrote:
>
> WHAT A TWAT!
>
> P.S.
>
> Yes, feel free to ban me, it was worth it.

Was it?

You could have used the word 'idiot', at least it is not an insult to
the feminine gender.
You could have as well quoted which part of the message you didn't
like. I'm taking you didn't like part 2.
This was obviously a provocative statement, but it was not an insult.

I still stand that the qt-projects.org domain should not be managed
(directly or indirectly) by the Qt Company, there is a clear conflict
of interest.
Something that has been raised several times in the past (Check the
mailing list archives about the captive/deceptive portal hat is/was
the Qt's download page).
lists.qt-projects.org has had issue for more than a month, and
(suddenly) got resolved overnight.
[Side note: http stopped to redirect to https, but https is still
down, which means that https urls returned by search engine are
broken. Whoever runs codereview.qt-project.org has access to a
wildcard ssl certificate (*.qt-project.org), but it seems that whoever
runs lists.qt-project.org doesn't.]

As an experience, try to type "download qt" in you favorite search
engine, and tell me what you get, here is my top results:
https://www.qt.io/download
https://www1.qt.io/offline-installers/
https://download.qt.io/archive/qt/
qt-project.org/downloads

The interesting bit is that  qt-project.org/downloads redirects to
https://www.qt.io/download.

Basically, qt-projects.org is just a facade to qt.io, I think this is
not healthy. There is no public expression of the "Qt Project".
Concerning, the "Qt Project Hosting Foundation", i've found:
https://wiki.qt.io/Qt-contributors-summit-2014-QtCS2104_Foundation
https://investors.qt.io/governance/management/ (where it is mentioned
that Tuukka Turunen is a "Chairman of the Board of Directors in the Qt
Project Hosting Foundation")

http://website.informer.com/Cristina+Hamley+Qt+Project+Hosting+Foundation.html


Chris

PS: I do not hate the Qt Company, nor do I hate anyone working for
them. Without license, without money, there would be no "Qt Company",
and without "Qt Company", the "Qt Project" would be substantially
different. As a license owner and an OSS enthusiast I am thankful to
the Qt Company and to all numerous direct and indirect "Qt Project"
contributors.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Who is in charge of qt-project.org?

[Tuukka Turunen]

Hi,

Materials related to contributing to Qt and Qt Project are still there, not 
been removed, see: https://www.qt.io/contribute-to-qt, 
https://wiki.qt.io/Qt_Contribution_Guidelines, 
https://wiki.qt.io/Qt_Project_Open_Governance, and 
https://wiki.qt.io/The_Qt_Governance_Model - just to mention a few pages about 
the Qt Project and contributing to Qt.

At the time of unification qt-project.org was mainly a site for developers 
using Qt, built in a way that it was really laborsome to maintain. Content was 
carried over to more modern systems for everything that was seen relevant - 
including all contribution related items (which already back then were in the 
wiki part of the system). Because the majority of people visiting 
www.qt-project.org were developers of Qt applications, it redirects to the 
current developer page. 

Things can always be improved, and constructive feedback is always welcome. But 
to claim the The Qt Company has removed everything related to the Qt Project is 
not justified in my opinion. Could these be more visible, probably. If you have 
suggestions, these can be done e.g. via: 
https://bugreports.qt.io/projects/QTWEBSITE. 

Yours,

Tuukka

On 01/11/2018, 11.02, "Development on behalf of Olivier Goffart" 
 wrote:

On 01.11.18 08:49, Tuukka Turunen wrote:
> 
> Hi Christian,
> 
> What comes to the mistake with the mailing list archive, we of course fix 
it. Meanwhile, use the workaround described by Andy: " It is there, but you 
have to go to http://lists.qt-project.org for now, it is being moved to a new 
server so at some point the https address will be back, but until then you need 
to use the http address."
> 
> What comes to the Qt Project, it is how Qt is developed - all the work 
done for Qt by The Qt Company is via the Qt Project. The website where this is 
best visible is: https://codereview.qt-project.org, also the mailing lists are 
with qt-project.org domain.
> 
> The reasons for not having a separate site for open-source Qt and 
commercial Qt are described quite well in this blog post from, 2014: 
http://blog.qt.io/blog/2014/08/06/defragmenting-qt-and-uniting-our-ecosystem/
> 
> The hosting foundation for Qt Project (a non-profit organization 
registered in Norway) is currently inoperable, costs of running the web 
servers, download systems etc of the Qt Project are paid directly by The Qt 
Company.

That blog you link said it would merge the contents of qt-project.org with 
the 
contents of digia. In practice, it just removed, or hide, all the contents 
from 
qt-project, and replaced it by The Qt Company marketing.

At the time, qt-project.org contained useful information for and from 
developers *of* Qt. The contribution model was explained, the blog links 
was 
linking to planet qt, an aggregation of contributors blog.

https://web.archive.org/web/20140806181527/http://qt-project.org:80/

Today, qt-project.org redirects to https://www.qt.io/developers/ which is 
use a 
page for developer *using* Qt. It contains only Qt Company links, The "Qt" 
blog 
is just "The Qt Company" blog. It does not really mention that there are 
contributors to Qt other than the Qt company.



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


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

Re: [Development] Who is in charge of qt-project.org?

[Tuukka Turunen]

Hi,

Of course mailing list discussion is also completely fine. But in case someone 
has a concrete suggestion related to any of the websites, it can be also 
submitted via JIRA. Just like feature suggestions. It may be to not everyone 
was aware of this, thus I provided the link.

Yours,

Tuukka

On 01/11/2018, 13.18, "Development on behalf of Uwe Rathmann" 
 wrote:

On Thu, 01 Nov 2018 10:24:16 +0000, Tuukka Turunen wrote:

> Things can always be improved, and constructive feedback is always
> welcome.

The bottom line of this all is of course the fundamental question if the 
Qt Project is intended to be more than simply a way how to contribute to 
the products of the Qt Company ?

If it isn't it would be a matter of honesty to move everything from qt-
project.org to qt.io and tell the truth to the Qt community.

Otherwise he Qt Company has to give the Qt Project more rights to make 
independent decisions - starting with having a clean separation between 
the resources owned by the Qt Project and the Qt Company.

> If you have suggestions, these can be done e.g. via:
> https://bugreports.qt.io/projects/QTWEBSITE.

Are you seriously trying to redirect complaints about how the Qt Company 
is misusing qt.project.org to qt.io ?

Uwe


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


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

Re: [Development] Who is in charge of qt-project.org?

[Tuukka Turunen]

Exactly. We are very pleased if there are people who start to contribute to 
Qbs. So far it has been very little by others than employees of The Qt Company. 

We will continue maintaining Qbs so that it stays supported until end of 2019 
and also release a new version in April 2019 as promised. Most likely Qbs 
remains usable a long time after support ends - even without anyone from the 
community working on it. 

This is a good opportunity for those interested in further developing Qbs to 
step up and start taking it forward. We can help with the reviews and provide 
the infrastructure. We can help even with new releases, if there is enough 
interest to develop it further. 

I do not think anyone questions the technical merits of Qbs over qmake or 
CMake. Qbs is better than these in many ways. For that reason we have kept on 
investing into it. But we also need to be realistic and think about what paying 
customers prefer. While we have some customers using Qbs, the use of CMake is 
much, much bigger. Both by the number of customers using it and by the size of 
the customers' usage.

We probably should have opened the dialogue about the future of Qbs during the 
process of thinking about the options. This would have been good and fair 
towards the community. But it would not change the facts - it is an impossibly 
huge task to replace CMake with Qbs even within the Qt users, let alone outside 
of Qt. 

Yours,

Tuukka

On 02/11/2018, 14.15, "Development on behalf of Martin Smith" 
 wrote:

>You've just dropped Qbs, what's next?
>I don't trust you anymore, nor the company-ies you represent - Nothing 
personal.
>I think that it is time for the qt-project.org domain to be handed
>back to the Qt Project community.

But "dropped Qbs" means The Qt Company won't be developing Qbs anymore, 
which means, effectively, Qbs is being handed to the Qt Project community.

martin


From: Development  
on behalf of Christian Gagneraud 
Sent: Friday, November 2, 2018 1:08:34 PM
To: Lars Knoll
Cc: development@qt-project.org; v.ro...@yahoo.it
Subject: Re: [Development] Who is in charge of qt-project.org?

On Fri, 2 Nov 2018 at 23:55, Lars Knoll  wrote:
>
>
> On 2 Nov 2018, at 11:45, Christian Gagneraud  wrote:
>
> On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
>  wrote:
>
>
>
> Hi,
> I have to apologise for my behaviour. While I still think Christian 
Gagneraud's attack on the Qt company abilities was unfair and uncalled for, 
it's not a justification for my actions.
> Creating an hostile environment is bad for the community and I should not 
have done it.
> It won't happen again,
> Regards,
> Luca
>
>
> Hi All,
>
> I would  like to apologise as well, my sarcasm and my provocation went
> uncontrolled.
> My fault, this was definitely not the most clever way to get things 
sorted.
> I'm looking forward HTTPS://lists.qt-project.org to be back online and
> would like to thanks everyone working on the matter.
>
>
> Thanks Chris and Luca.
>
> Getting lists.qt-project.org fixed is being worked on. I hope it’s won’t 
be too long.
>
> But there’s something to take away for TQtC as the party taking care of 
the infrastructure here. TQtC needs to establish some more pro-active 
monitoring of the infrastructure so that these things will get ideally get 
fixed before they become a problem next time. I’ll see what I can do to help 
getting that in place.



Hi Lars,

You've just dropped Qbs, what's next?
I don't trust you anymore, nor the company-ies you represent - Nothing 
personal.
I think that it is time for the qt-project.org domain to be handed
back to the Qt Project community.
I was reading a french article this morning
(https://linuxfr.org/news/fedora-29), i give you an inaccurate, but
syntactic and compact translation of the article introduction:

Fedora is a GNU/Linux distribution developed by the Fedora Project and
sponsored by Red Hat that provide them with developers, finance and
logistics.
Fedora can be seen as an open source technological show case of Red
Hat proprietary technology. (NDLR: Free and inaccurate translation, i
mean it)
=> sold for 34 billions dollars

How do you fell about that? Do you see similarities?

Is the triple-licensed Qt stack an open source technological show case
of what the Qt Company has to offer?


More seriously, yes, Fedora/RedHat  and
Qt/Project/Company/Digia/Nokia/Microsoft/TrollTech are different beast
(apple and oranges, yadi, yada, ...).
But I see similarities. (and i do not care about the 34 billions)

Chris
___
Development mailing list
Development@qt-proje

Re: [Development] Who is in charge of qt-project.org?

[Tuukka Turunen]

Here is what I replied to the mail (when sent to me only):

Hi,

This is absolutely true and we are well aware of this.

We had a bit similar issue earlier when we ramped down engin.io backend: 
https://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users/

We try to avoid such things as much as possible, but sometimes we have to stop 
developing some item. Even when there are still users who depend upon it.

We also try to make it as smooth as we can – for example by keeping the 
deprecated feature usable for quite long time to allow enough time for 
transition.

Yours,

Tuukka


From: NIkolai Marchenko 
Date: Friday, 2 November 2018 at 15.11
To: Tuukka Turunen 
Cc: Martin Smith , Christian Gagneraud , 
Lars Knoll , Qt development mailing list 
, "v.ro...@yahoo.it" 
Subject: Re: [Development] Who is in charge of qt-project.org?

(thiws was  originally sent only to Tuukka, resending)

I would also like to point out the mistrust you've created by proxy.
In believing your promises people have migrated projects at their jobs to qbs.
Now they will be known as too hasty adopters of dead systems.
Not saying it will be the case for everyone but what you did *really* hurts 
your early adopters in more than one way.

On Fri, Nov 2, 2018 at 3:44 PM Tuukka Turunen 
mailto:tuukka.turu...@qt.io>> wrote:

Exactly. We are very pleased if there are people who start to contribute to 
Qbs. So far it has been very little by others than employees of The Qt Company.

We will continue maintaining Qbs so that it stays supported until end of 2019 
and also release a new version in April 2019 as promised. Most likely Qbs 
remains usable a long time after support ends - even without anyone from the 
community working on it.

This is a good opportunity for those interested in further developing Qbs to 
step up and start taking it forward. We can help with the reviews and provide 
the infrastructure. We can help even with new releases, if there is enough 
interest to develop it further.

I do not think anyone questions the technical merits of Qbs over qmake or 
CMake. Qbs is better than these in many ways. For that reason we have kept on 
investing into it. But we also need to be realistic and think about what paying 
customers prefer. While we have some customers using Qbs, the use of CMake is 
much, much bigger. Both by the number of customers using it and by the size of 
the customers' usage.

We probably should have opened the dialogue about the future of Qbs during the 
process of thinking about the options. This would have been good and fair 
towards the community. But it would not change the facts - it is an impossibly 
huge task to replace CMake with Qbs even within the Qt users, let alone outside 
of Qt.

Yours,

Tuukka

On 02/11/2018, 14.15, "Development on behalf of Martin Smith" 
mailto:qt...@qt-project.org>
 on behalf of martin.sm...@qt.io<mailto:martin.sm...@qt.io>> wrote:

>You've just dropped Qbs, what's next?
>I don't trust you anymore, nor the company-ies you represent - Nothing 
personal.
>I think that it is time for the qt-project.org<http://qt-project.org> 
domain to be handed
>back to the Qt Project community.

But "dropped Qbs" means The Qt Company won't be developing Qbs anymore, 
which means, effectively, Qbs is being handed to the Qt Project community.

martin


From: Development 
mailto:qt...@qt-project.org>>
 on behalf of Christian Gagneraud mailto:chg...@gmail.com>>
Sent: Friday, November 2, 2018 1:08:34 PM
To: Lars Knoll
Cc: development@qt-project.org<mailto:development@qt-project.org>; 
v.ro...@yahoo.it<mailto:v.ro...@yahoo.it>
Subject: Re: [Development] Who is in charge of 
qt-project.org<http://qt-project.org>?

On Fri, 2 Nov 2018 at 23:55, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:
>
>
> On 2 Nov 2018, at 11:45, Christian Gagneraud 
mailto:chg...@gmail.com>> wrote:
>
> On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
> mailto:development@qt-project.org>> wrote:
>
>
>
> Hi,
> I have to apologise for my behaviour. While I still think Christian 
Gagneraud's attack on the Qt company abilities was unfair and uncalled for, 
it's not a justification for my actions.
> Creating an hostile environment is bad for the community and I should not 
have done it.
> It won't happen again,
> Regards,
> Luca
>
>
> Hi All,
>
> I would  like to apologise as well, my sarcasm and my provocation went
> uncontrolled.
> My fault, this was definitely not the most clever way to get things 
sorted.
> I'm looking forward HTTPS://lists.qt-project.org to be back onli

[Development] Closing bugs as won't fix or out of scope

[Tuukka Turunen]

Hi,

I was looking a bit into our older bugs and found quite many that in my opinion 
could be closed. We do not have a QUIP to define the policy of closing bugs 
currently, so this is a bit of a matter of viewpoint. In my opinion we should 
be more active in closing a bug that no-one has an intention of fixing. If the 
bug later turns out to be relevant to fix, it can always be re-opened.

Some of the bugs I was looking at were

  *   reported to happen in some exotic device, sometimes also quite old one 
(by now, if bug has been hanging for a long time)
  *   reported to happen only in an old version of the operating system
  *   fixed in a later version of Qt, but left open as bug was not feasible to 
fix in the version it was reported from
  *   reported for old version of Qt, and no longer relevant functionality in 
the current versions
  *   caused by a bug in the operating system
  *   maybe possible to fix, but with a risk of causing a regression or a 
behavior change
  *   such that would require a major rewrite of the functionality to fix
  *   not reproduceable any more (or reported by the user not to be able to 
reproduce)
  *   marked as duplicate, but both instances of the bug were open/reported 
state
  *   not actually bugs, but suggestions for new functionality reported as a 
bug (should be moved to be a suggestion)

Different persons have unique viewpoints to what kind of bug should be closed 
and what not. Keeping everything open until the reported issue fixed, is also a 
valid view, but that leads to a large number of bugs and can hinder getting the 
right understanding of what is planned to be fixed or finding the important 
items to fix. Of course sometimes we also simply forget to close a bug or some 
bug gets fixed in conjunction of other changes (and bug report is not closed).

I am not saying that we should necessarily close immediately all and every bug 
that match criteria I mentioned in the bullet list. What would be good is a bit 
more of a common agreement of what to do with the bugs that are not indented to 
be fixed (or at least very likely not going to be fixed).

Yours,

Tuukka
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Closing bugs as won't fix or out of scope

[Tuukka Turunen]

Hi,

Would be great if you add that info as a comment to the bug reports.

Yours,

Tuukka

From: Massimo Callegari 
Date: Thursday, 8 November 2018 at 15.05
To: Qt Project Development Mailing List , Tuukka 
Turunen 
Subject: Re: [Development] Closing bugs as won't fix or out of scope

Hello Tuukka,
on my end you can close the following.

https://bugreports.qt.io/browse/QTBUG-58987
https://bugreports.qt.io/browse/QTBUG-46707
https://bugreports.qt.io/browse/QTBUG-49788
https://bugreports.qt.io/browse/QTBUG-53580
https://bugreports.qt.io/browse/QTBUG-44923

I do believe Qt3D issues need some more love by maintainers.
For example https://bugreports.qt.io/browse/QTBUG-69721 is a plain regression 
reported on August 1st and completely ignored.

This can also be closed: https://bugreports.qt.io/browse/QTBUG-62578 (not 
reproduced anymore with recent Qt versions)

Thanks,
Massimo

Il giovedì 8 novembre 2018, 13:05:53 CET, Tuukka Turunen  
ha scritto:
Hi,

I was looking a bit into our older bugs and found quite many that in my opinion 
could be closed. We do not have a QUIP to define the policy of closing bugs 
currently, so this is a bit of a matter of viewpoint. In my opinion we should 
be more active in closing a bug that no-one has an intention of fixing. If the 
bug later turns out to be relevant to fix, it can always be re-opened.



Some of the bugs I was looking at were

· reported to happen in some exotic device, sometimes also quite old 
one (by now, if bug has been hanging for a long time)

· reported to happen only in an old version of the operating system

· fixed in a later version of Qt, but left open as bug was not feasible 
to fix in the version it was reported from

· reported for old version of Qt, and no longer relevant functionality 
in the current versions

· caused by a bug in the operating system

· maybe possible to fix, but with a risk of causing a regression or a 
behavior change

· such that would require a major rewrite of the functionality to fix

· not reproduceable any more (or reported by the user not to be able to 
reproduce)

· marked as duplicate, but both instances of the bug were open/reported 
state

· not actually bugs, but suggestions for new functionality reported as 
a bug (should be moved to be a suggestion)



Different persons have unique viewpoints to what kind of bug should be closed 
and what not. Keeping everything open until the reported issue fixed, is also a 
valid view, but that leads to a large number of bugs and can hinder getting the 
right understanding of what is planned to be fixed or finding the important 
items to fix. Of course sometimes we also simply forget to close a bug or some 
bug gets fixed in conjunction of other changes (and bug report is not closed).



I am not saying that we should necessarily close immediately all and every bug 
that match criteria I mentioned in the bullet list. What would be good is a bit 
more of a common agreement of what to do with the bugs that are not indented to 
be fixed (or at least very likely not going to be fixed).



Yours,



Tuukka
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Tuukka Turunen]

Thanks, Jani.

I would like to remind that just like with Qt 5.9 LTS, we aim to have frequent 
patch releases of Qt 5.12 LTS. So there is no need to get every possible fix 
into Qt 5.12.1 as the Qt 5.12.2 is anyway coming soon, after that Qt 5.12.3 and 
so on. 

So let's keep pushing bug fixes into the 5.12 branch, it won't be long until 
these are part of a patch level release.

Yours,

Tuukka 

On 08/01/2019, 10.04, "Releasing on behalf of Jani Heikkinen" 
 wrote:

Hi all,

Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
qttools is  still ongoing, there were some conflicts and so on manual merge + 
normal integration is needed there. Work is ongoing and should be ready today. 

So from now on '5.12.1' is for soon coming Qt 5.12.1 release and staging 
there is restricted to release team only. And '5.12' is for Qt 5.12.2.

Target is to get Qt 5.12.1 out as soon as possible. We will create initial 
changes files soon so please finalize those immediately to be able to proceed 
with the release. Release blocker list here: 
https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
blockers are visible in the list!

We will release first snapshot for Qt 5.12.1 during this week as well

br,
Jani

From: Development  on behalf of Jani 
Heikkinen 
Sent: Monday, January 7, 2019 7:37 AM
To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   '5.12.1'
started

> -Original Message-
> From: Development  On Behalf Of
> Aleksey Kontsevich
> Sent: lauantai 5. tammikuuta 2019 12.23
> To: ekke ; developm...@lists.qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
> started
>
> Hi,
>
> What about QTBUG-72687 and QTBUG-72227?
>
QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.

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

[Development] Requesting a repository for Lottie-Qt implementation

[Tuukka Turunen]

Hi,

I would like to request for a new repository:

Name of the repository: qt/qtlottie.git
Description: Lottie-Qt, a renderer for Bodymovin animations
Responsible person: Eirik Aavitsland
Gerrit user/email: eirik.aavitsl...@qt.io

Lottie is a family of player software for a certain json-based  file format for 
describing 2d vector graphics animations. These files are created/exported 
directly from After Effects by a plugin called Bodymovin.

About Lottie: https://airbnb.design/lottie/

Intention is to create a Qt based player for these animations and license it 
under GLPv3 and commercial licenses.

Yours,

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

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Tuukka Turunen]

Hi Thiago,

Lottie is the established term for a player of animations created with Adobe 
After Effects and exported with a plugin tool called Bodymovin.

Lottie is a registered trademark for many things (like nail polish, children's 
toys and food), but it is not registered as a trademark for the player of 
Bodymovin animations (or anything close to it).

See https://airbnb.io/lottie/: "Lottie is named after a German film director 
and the foremost pioneer of silhouette animation." and "Lottie is a mobile 
library for Android and iOS that parses Adobe After Effects animations exported 
as json with Bodymovin and renders them natively on mobile and on the web!"

Therefore we believe the right name for this little thing is Lottie-Qt.

Yours,

Tuukka

On 09/01/2019, 19.52, "Development on behalf of Thiago Macieira" 
 
wrote:

On Wednesday, 9 January 2019 06:23:02 PST Tuukka Turunen wrote:
> Description: Lottie-Qt, a renderer for Bodymovin animations

What's "Lottie" ? Is that an acronym? Or is it a trademark of something? If 
it's the latter, please find another name.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
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 Lottie-Qt implementation

[Tuukka Turunen]

Hi Eike,

Great, the more the merrier. After we have the repo in place, I hope you can 
also take a look into what we have in mind as approach for the player. 

Maybe one day these can be compared, perhaps combined or otherwise unified. 

Yours,

Tuukka

On 09/01/2019, 19.31, "Development on behalf of Eike Hein" 
 wrote:

Hi,

we've written one of those at KDE recently:

https://github.com/kbroulik/lottie-qml

We also submitted some patches to both Qt and Lottie to make it work
better.

Ours is LGPLv2+ as usual, FWIW.



Cheers,
Eike

On 1/9/19 11:23 PM, Tuukka Turunen wrote:
>  
> 
> Hi,
> 
>  
> 
> I would like to request for a new repository:
> 
>  
> 
> Name of the repository: qt/qtlottie.git
> 
> Description: Lottie-Qt, a renderer for Bodymovin animations
> 
> Responsible person: Eirik Aavitsland
> 
> Gerrit user/email: eirik.aavitsl...@qt.io <mailto:eirik.aavitsl...@qt.io>
> 
>  
> 
> Lottie is a family of player software for a certain json-based  file
> format for describing 2d vector graphics animations. These files are
> created/exported directly from After Effects by a plugin called Bodymovin.
> 
>  
> 
> About Lottie: https://airbnb.design/lottie/
> 
>  
> 
> Intention is to create a Qt based player for these animations and
> license it under GLPv3 and commercial licenses.
> 
>  
> 
> Yours,
> 
>  
> 
> Tuukka
> 
> 
> ___
> 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] Requesting a repository for Lottie-Qt implementation

[Tuukka Turunen]

Hi,

Sometimes parallel work happens - especially if things are done outside of the 
Qt Project repositories. Sometimes there is real duplication of effort, 
sometimes approach is different even though aiming towards the same goal, 
performance may differ, 3rd party dependencies are different etc. So not 
everything that at first look seems duplicate actually is. 

Related to your comment about the Qt Charts being limited I would tend to 
disagree. While there of course are always thing that can be added, it does 
support a wide variety of different chart types and functionality.

Discussion about Qt Charts is of course welcome, but perhaps not that relevant 
for discussion about creating a new repository for Lottie-Qt.

Yours,

Tuukka

On 10/01/2019, 11.58, "Development on behalf of Uwe Rathmann" 
 
wrote:

On Thu, 10 Jan 2019 07:24:01 +, Frederik Gladhorn wrote:

>> Ours is LGPLv2+ as usual, FWIW.
> 
> Which sadly makes it unsuitable for inclusion in Qt.

I'm maintainer of the Qwt library ( https://qwt.sourceforge.io/ ), that 
exists since Qt 1.1 - but there are also other popular Qt plotting 
libraries available. For some reason "Qt" decided to come up with the Qt/
Charts module many years later - AFAIK without even trying to contact any 
existing project.

As being author of a competing package I never checked the code of the Qt/
Chart module and can't ( and don't want to ) judge if it is good or bad. 
But my impression is, that it started with a limited set of features and 
immediately changed into maintenance mode without seeing much active 
development since then.

Don't you agree that supporting an existing project instead would have 
lead to a better overall situation for everyone ?

Considering that you hardly get the existing modules maintained - why 
don't you start with thinking in a more community oriented way ?

Uwe


___
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 Lottie-Qt implementation

[Tuukka Turunen]

Thanks!


Yours,

Tuukka


Lähettäjä: Development  käyttäjän Paul 
Wicking  puolesta
Lähetetty: perjantaina, tammikuuta 11, 2019 4:48 ip.
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Requesting a repository for Lottie-Qt implementation

On 1/9/19 3:23 PM, Tuukka Turunen wrote:
>
> Hi,
>
> I would like to request for a new repository:
>
> Name of the repository: qt/qtlottie.git
> Description: Lottie-Qt, a renderer for Bodymovin animations
> Responsible person: Eirik Aavitsland
> Gerrit user/email: eirik.aavitsl...@qt.io<mailto:eirik.aavitsl...@qt.io>
>
> Lottie is a family of player software for a certain json-based file format 
> for describing 2d vector graphics animations. These files are 
> created/exported directly from After Effects by a plugin called Bodymovin.
>
> About Lottie: https://airbnb.design/lottie/
>
> Intention is to create a Qt based player for these animations and license it 
> under GLPv3 and commercial licenses.
>
> Yours,
>
> Tuukka
>
>
>

Hi,

the repository has been created and can be found here:
https://codereview.qt-project.org/#/admin/projects/qt/qtlottie

It's ready for use.

Paul
___
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: Branching from '5.12' to '5.12.1' started

[Tuukka Turunen]

Hi,

Some release blocker bugs have been found in the testing, so we'll need a few 
fixes before the release.

For more details, see: https://bugreports.qt.io/issues/?filter=20430 

Yours,

Tuukka

On 14/01/2019, 12.59, "Development on behalf of ekke" 
 wrote:

Hi,
are there any news abolut Qt 5.12.1 release ?

thanx

ekke

Am 09.01.19 um 09:56 schrieb Liang Qi:
> qtbase and qttools final down merges are done,
>
> https://codereview.qt-project.org/#/c/249324/
> https://codereview.qt-project.org/#/c/249362/
>
> And also qt5 5.12->5.12.1 final down merge is done,
>
> https://codereview.qt-project.org/#/c/249362/
>
> —Liang
>
>> On 8 Jan 2019, at 08:32, Jani Heikkinen  wrote:
>>
>> Hi all,
>>
>> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and 
qttools is  still ongoing, there were some conflicts and so on manual merge + 
normal integration is needed there. Work is ongoing and should be ready today. 
>>
>> So from now on '5.12.1' is for soon coming Qt 5.12.1 release and staging 
there is restricted to release team only. And '5.12' is for Qt 5.12.2.
>>
>> Target is to get Qt 5.12.1 out as soon as possible. We will create 
initial changes files soon so please finalize those immediately to be able to 
proceed with the release. Release blocker list here: 
https://bugreports.qt.io/issues/?filter=20430 Please make sure all release 
blockers are visible in the list!
>>
>> We will release first snapshot for Qt 5.12.1 during this week as well
>>
>> br,
>> Jani
>> 
>> From: Development  on behalf of Jani 
Heikkinen 
>> Sent: Monday, January 7, 2019 7:37 AM
>> To: Aleksey Kontsevich; ekke; developm...@lists.qt-project.org
>> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to   '5.12.1' 
   started
>>

___
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.13 feature freeze is getting closer

[Tuukka Turunen]

Hi,

The API is relatively simple, so reviewing and fixing the findings should not 
be a problem. As this is a new module, would definitely be good to do an 
initial API review now / before alpha. We probably anyway want to include it 
first as a TP, so its API is not yet fixed/final even with Qt 5.13.0.

Yours,

Tuukka



Lähettäjä: Development  käyttäjän Oliver 
Wolff  puolesta
Lähetetty: keskiviikkona, tammikuuta 16, 2019 8:56 ap.
Vastaanottaja: Aleksey Kontsevich; development@qt-project.org
Aihe: Re: [Development] Qt 5.13 feature freeze is getting closer

On 15/01/2019 16:42, Aleksey Kontsevich wrote:
>> There were lots of comments about coding style and the generic approach
>
> That were fixed.

The inline comments might have been fixed, but there was quite some
disagreement about the patch's status after it was merged. That's
reflected by the comments that were added to the initial patch set after
the merge, so I think there is still more work to be done.

>
>
>> Additionally no API review has taken place yet.
>
> That was not done - true.

API reviews are an essential aspect for new Qt modules and they can take
quite some time until they are done and agreed upon.

I just wanted to let you know, that getting Qt Telemetry (or whatever it
will be called) will still be a lot of work and it's much more than just
including the current "module" into qt5.git.

Olli

>
> --
> Best regards,
> Aleksey
> Linked in https://www.linkedin.com/in/alekseykontsevich
>
>
> 15.01.2019, 09:55, "Oliver Wolff" :
>> Hi Aleksey,
>> On 14/01/2019 18:50, Aleksey Kontsevich wrote:
>>>  Hi,
>>>
>>>  Whether Qt Telemetry module will be included:
>>>  
>>> https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summary
>>>  ?
>>
>> If I remember correctly, there was quite a large amount of comments
>> about the initial patch. As far as I can see, there were no followup
>> commits so I think the status still is, that there is still a lot of
>> work to be done until the module can be part of Qt (even as tech preview).
>>
>> There were lots of comments about coding style and the generic approach
>> for example. Additionally no API review has taken place yet.
>>
>> I doubt that the module will be ready in time for 5.13 in its current state.
>>
>> Best regards,
>> Olli
>>
>>>  --
>>>  Best regards,
>>>  Aleksey
>>>  Linked in https://www.linkedin.com/in/alekseykontsevich
>>>
>>>  14.01.2019, 13:01, "Jani Heikkinen" :
  Hi all,

  There is only a bit more than two week to Qt 5.13 feature freeze, see 
 https://wiki.qt.io/Qt_5.13_Release. At this point we should already know 
 if there will be some new submodules in Qt 5.13 so please get possible new 
 submodule in qt5 as soon as possible; those really needs to be in before 
 we start soft branching (25.1.2019)! And of course inform us about those 
 new submodules; we need to create packaging configurations for
  those as well.

  And please start updating Qt 5.13 new features page here: 
 https://wiki.qt.io/New_Features_in_Qt_5.13

  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
___
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.13 feature freeze is getting closer

[Tuukka Turunen]

Hi,

I think best would be to do the API review in codereview tool as mailing lists 
are of limited efficiency in this purpose. Based on the API review we can then 
decide if the module is ready to be part of Qt 5.13 as TP or not. For the 
existing modules we do the API review a bit later, but for the proposed new 
modules we could well do it already now - if not recently completed.

Yours,

Tuukka

On 17/01/2019, 15.28, "Development on behalf of Christian Stenger" 
 wrote:

Nope, I'm talking about the module.. But inside the plugin review I try to 
limit my criticism to the QC part as there are more competent developer to tell 
you how to do the stuff correctly inside a Qt module.

But even I see lots of stuff there that is a plain mess and should not be a 
part of Qt in its current state.



From: Aleksey Kontsevich 
Sent: Thursday, January 17, 2019 2:07:19 PM
To: Christian Stenger; Maurice Kalinowski; Lars Knoll; Thiago Macieira
Cc: Qt development mailing list
Subject: Re: [Development] Qt 5.13 feature freeze is getting closer

Your are mostly talking about the plugin not telemetry module which is ok 
now. And even in the plugin most of your concerns related not to API or logic 
(there was much misunderstanding) like code styling and conventions explicit 
keyword for ctor, connect() styles, comments, etc.

--
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


17.01.2019, 14:19, "Christian Stenger" :
>> There were not concerns about code quality, :) was concerns about code 
styles conventions, etc. All of these was fixed, only qdoc left to do
>
> You must be kidding... This is still a complete mess and definitely not 
ready for more than a playground.
>
> 
> From: Development  on behalf of 
Aleksey Kontsevich 
> Sent: Thursday, January 17, 2019 1:03:55 PM
> To: Maurice Kalinowski; Lars Knoll; Thiago Macieira
> Cc: Qt development mailing list
> Subject: Re: [Development] Qt 5.13 feature freeze is getting closer
>
>> That is beside all the concerns about the quality of the code and 
missing actions to fix these.
>
> There were not concerns about code quality, :) was concerns about code 
styles conventions, etc. All of these was fixed, only qdoc left to do.
>
> --
> Best regards,
> Aleksey
> Linked in https://www.linkedin.com/in/alekseykontsevich
>
> 17.01.2019, 10:22, "Maurice Kalinowski" :
>>  Well even for TP there should be some consensus on whether it should be 
part of Qt or not, no?
>>
>>  We are lacking documentation on the process here, all I could find was 
https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Graduating_from_the_Playground.
>>
>>  “This decision is done on the qt-development mailing list, based on the 
technical and spirit fit to Qt, and it requires the approval of the Chief 
Maintainer.”
>>
>>  To my knowledge this has not happened at all. There was only a 
repository request so far, none for integrating it into the product line.
>>
>>  That is beside all the concerns about the quality of the code and 
missing actions to fix these.
>>
>>  Maurice
>>
>>  From: Development  On Behalf Of 
Lars Knoll
>>  Sent: Wednesday, January 16, 2019 8:56 PM
>>  To: Thiago Macieira 
>>  Cc: Qt development mailing list 
>>  Subject: Re: [Development] Qt 5.13 feature freeze is getting closer
>>
>>>  On 16 Jan 2019, at 19:54, Thiago Macieira  
wrote:
>>>
>>>  On Wednesday, 16 January 2019 09:44:40 PST Aleksey Kontsevich wrote:
>>>
  In Nov, there was long discussion in review:
  https://codereview.qt-project.org/#/c/240347/ Request was initially 
for
  both: plugin and library - latter was transformed to Qt module.
>>>
>>>  Given that this is a complete surprise, I don't think we can find 
enough time
>>>  to do a review of it as a module in time for 5.13.
>>
>>  As far as I understood it the request was for a TP status, not a fully 
supported module.
>>
>>>  In particular, I want to
>>>  take a look to see how it can integrate with a project my team is 
working on:
>>>   
https://clearlinux.org/documentation/clear-linux/concepts/telemetry-about
>>
>>  Why should that project influence a telemetry module for Qt?
>>
>>>  So I think that for 5.13, the module can be at no higher state than
>>>  experimental. That will allow getting API reviews and testing by 
others.
>>
>>  See above, I don’t think anything else was being asked for.
>>
>>  Cheers,
>>
>>  Lars
>>
>>  ,
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  https://lists.qt

Re: [Development] Qt 5.13 feature freeze is getting closer

[Tuukka Turunen]

Hi,

Yes, I was thinking that we could use a slightly similar approach for the new 
modules as we do for the API change reviews (to the extent applicable, 
considering we do not have anything to automatically compare to etc). That 
said, we may be too close to Qt 5.13 feature freeze to fully do that for all 
the candidate new modules before FF. Perhaps the most viable approach would be 
to do the review fixes before Beta 1 release - and in case not adequately fixed 
to be a technology preview, drop it out before the Beta 1. We should also 
decide what is the policy we use for Qt 5.14 onwards regarding timing of API 
reviews and add to https://wiki.qt.io/Qt_5_Feature_Freeze.  

Yours,

Tuukka

On 17/01/2019, 16.11, "Edward Welbourne"  wrote:

    Tuukka Turunen (17 January 2019 15:00)
> I think best would be to do the API review in codereview tool as
> mailing lists are of limited efficiency in this purpose. Based on the
> API review we can then decide if the module is ready to be part of Qt
> 5.13 as TP or not. For the existing modules we do the API review a bit
> later,

As I suspect you're thinking of the API reviews I create in the run-up
to a release, I feel obliged to point out these are really API *change*
reviews.  Without a prior release to compare against, the tool for that
doesn't know how to report anything.  You need an actual review of the
whole API, not just some recent changes to it.

> but for the proposed new modules we could well do it already now - if
> not recently completed.

I don't know of an established process for API review (that reviews the
whole of an API, not just what's lately changed).  We surely need one
(and it might not hurt to do them to old existing APIs, also, from time
to time), in particular for use when considering a new module.

Eddy.


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

Re: [Development] [Releasing] HEADS-UP: Branching '5.13' from 'dev' started

[Tuukka Turunen]

Hi,

Very little content yet at: https://wiki.qt.io/New_Features_in_Qt_5.13

There has been many changes worth mentioning pushed to dev during the past 6 
months. Please add these to wiki. 

I hope that by end of this week we have much more content in the page as Alpha 
release milestone is approaching soon.

Yours,

Tuukka

On 28/01/2019, 18.42, "Releasing on behalf of Jani Heikkinen" 
 wrote:

Hi,

We have soft branched '5.13' from 'dev' now. Final downmerge and Qt 5.13 
Feature Freeze will happen Friday 1st February. So please start using '5.13' 
now for new changes targeted to Qt 5.13 release

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

[Development] Qt Telemetry repository removed due to a possible copyright violation

[Tuukka Turunen]

Dear Qt developers,

We have removed Qt Telemetry repository from the Qt Project playground due to a 
possible copyright violation.

Based on analysis of the code, we have a reason to believe some of the 
contributed code is in violation of the Qt Project CLA.

According to the Qt Project CLA all contributions must be original work of the 
person making the contribution. Copying code that is written by someone else, 
removing the original copyright notices, and contributing the code as one’s own 
work is completely unacceptable.

While not all of the code in the Qt Telemetry repository are violating other’s 
copyrights, we have now removed the whole repository from the Qt Project 
playground.

If someone has cloned the Qt Telemetry repository, please delete it immediately 
and do not use it.

Yours,

Tuukka


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

Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages

[Tuukka Turunen]

Hi,

I do agree that we should avoid dropping configurations in patch releases. 
However, we should be pragmatic and provide the set that is most valuable for 
the users and still feasible to maintain. So in my opinion adding something and 
removing another is fine if that is what best serves our users. That said, we 
should not do this very often as LTS is about continuity. 

Yours,

Tuukka


On 06/02/2019, 14.24, "Development on behalf of Alex Blasche" 
 wrote:

> -Original Message-
> From: Development  On Behalf Of
> The mail did not state 5.12.x. Hence it was under the assumption "as 
always"
> with the next minor release.

As the person who initiated this, I have a bit of an ambivalent view point. 
Fact is, we have always made those changes for the next minor release and not 
in the middle of a patch release series. It provides essential continuity for 
our users especially for an LTS release. I would not want this policy being 
changed. Whatever is the outcome in this case, this rule should stay.

The question is now whether we should revert the above change and truly 
make it happen in 5.13+. Reason for the change was the large resounding request 
for the mingw 32bit binaries and Olli and me purposely picked a WinRT build 
with the least usage (based on our understanding). LTS will go on for some 
time. 

Personally, I would vote for an exception to acquiesce the demand.

--
Alex
___
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] Changes planned for the online installer

[Tuukka Turunen]

Hi,

Online installer has over time become quite crowded with different releases and 
many have noticed that it is getting quite slow at times. Having all this 
default content is also problematic for those who mirror Qt as it would take a 
significant amount of disk space to have a complete mirror.

From user viewpoint it could be seen handy that all these different releases 
are available via the online installer, but there are caveats. One major item 
is security. We always recommend to take the latest supported patch release, 
but have offered also all the old ones. It should be more clear than today to 
users what release to take. Unsupported releases contain multiple known 
vulnerabilities and should not be used.

With an upcoming version of the online installer, we are planning to make the 
following changes:

  *   Separate the pre-releases to its own ‘preview’ category, only visible 
when enabled
  *   Remove all unsupported Qt releases from the online installer
  *   Move all but the latest patch releases of supported Qt releases into 
‘archive’ category

This allows for greatly improved user experience of the online installer, 
focuses users to take the latest release with all security updates and reduces 
the space needed from the mirrors.

Commercial online installer uses Amazon CDN and for the commercial users we are 
planning to offer some the older, unsupported releases. There is also extended 
support available for those commercial license holders who are using an 
otherwise unsupported release of Qt.

Old Qt releases continue to be available for everyone in the 
download.qt.io historical archive, but in general they 
should be considered as a historical reference, not used in active projects.

Feedback and thoughts welcome. The topic could also be taken to the agenda of 
next week’s release team meeting?

Yours,

Tuukka





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

Re: [Development] Changes planned for the online installer

[Tuukka Turunen]

> On 19/03/2019, 15.47, "Sze Howe Koh"  wrote:
>
>I made a tool to help with (B), but it was meant to be a quick and
>dirty hack [3]. I didn't expect it to still be in use 5 years later.
>Please provide the ability to override the default mirror within the
>installer itself.


Thanks for the feedback. It is true that sometimes user gets a "wrong" mirror, 
but good thing is that oftentimes the mirror given by the system is a good one. 
So far we have not planned to make manual mirror selection part of the 
installer as it could also be confusing.

Another approach that would help is to have more mirrors and to have the 
content synced faster (and give more time to sync - sometimes we have tried to 
wait a day before making the release announcement). 

This would be a good opportunity to recommend everyone to contact your local 
"ftp server" providers and ask if they could mirror Qt. We do not have any 
mirror in Australia, for example. We do have quite nice amount of mirrors, but 
there is always room for more: https://download.qt.io/static/mirrorlist/ 

Instructions on how to become a mirror are: https://wiki.qt.io/Mirror_howto 

Yours,

Tuukka

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

Re: [Development] Changes planned for the online installer

[Tuukka Turunen]

Great, thanks!

--
Tuukka

On 25/03/2019, 12.22, "Florian Bruhin"  wrote:

On Mon, Mar 25, 2019 at 07:22:59AM +0000, Tuukka Turunen wrote:
> This would be a good opportunity to recommend everyone to contact your 
local
> "ftp server" providers and ask if they could mirror Qt. We do not have any
> mirror in Australia, for example. We do have quite nice amount of mirrors,
> but there is always room for more: 
https://download.qt.io/static/mirrorlist/ 

FWIW I've asked https://mirror.init7.net/ in Switzerland - let's see what 
they
think :)

Florian

-- 
https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
   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] Shadertools repo request and some words about state of graphics

[Tuukka Turunen]

On 04/04/2019, 10.54, "Development on behalf of Mike Krus via Development" 
 
wrote:

>Since Qt 3D Studio now contains, for lack of a better word, a fork of much 
> of Qt 3D, do you have ideas for that? And plans to integrate the work into 
> main line Qt 3D?

Qt 3D Studio 2.3.0 runtime depends on Qt 3D of Qt 5.12.2, it is not a fork or 
Qt 3D. When developing Qt 3D Studio runtime 2.x we have actually already done a 
lot of work also in Qt 3D and there are not a whole lot of items that would be 
directly applicable to Qt 3D that are not already part of it. Some items may 
exist that could be brought over to Qt 3D, for example KTX package format. But 
in general there is not that much items that would be useful as part of Qt 3D, 
without the Qt 3D Studio.

Yours,

Tuukka 

___
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

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

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

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

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

[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] 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&D | 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] 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] 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

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

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,

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,

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] Proposal for dev

[Tuukka Turunen]

+1

From: Development  on behalf of Hausmann 
Simon 
Date: Tuesday 28. January 2020 at 13.54
To: Qt Project Development 
Subject: [Development] Proposal for dev

Hi,

We have two things going on in dev right now:

(1) Quite many changes are going into qtbase right now that change 
fundamentals, in a very positive way, I'd say. And more changes are scheduled. 
These typically require follow-up fixes in other repositories, due to use of 
private API or relying on internals for example.

(2) We have the dependencies.yaml mechanism in place to allow for those 
changes to happen in one step instead of three.


The second step is very slow at the moment, for a few reasons. One of them is 
that there are many modules to take care of. Sometimes breaking changes also 
overlap, so before all repos have received fixes, a new breaking change lands 
in qtbase. As a consequence the last time all repositories passed the build and 
tests together was in the second half of October in the last decade ;-).

I'd like to propose the following change:

(1) All repositories remain active with their CI and anybody can submit 
fixes to the code/tests and updates to the dependencies.yaml.

(2) The automatic update of dependencies.yaml with the subsequent qt5.git 
update however is reduced to a smaller set of repositories.

(3) Once the dust has settled a bit in qtbase, we re-add more repositories 
to the automatic update. This would happen in a concentrated effort and also 
presents an opportunity to write/polish/improve porting documentation.

The proposal comes down to this change:

https://codereview.qt-project.org/c/qt/qt5/+/288059

I've taken the liberty of producing such a smaller set, but we can of course 
discuss additions/removals in Gerrit. And just to emphasize again: If a 
repository is not in this set, it's still CI covered of submitted changes. And 
I'd encourage anyone doing breaking changes to consider applying fixes to all 
repositories.

What do you think?

Simon

___
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 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] 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 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] 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] (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] [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] [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] 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
https://lists.qt-project.org/listinfo/develop

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

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] 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 
(a

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] 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] 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] 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] 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] 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] Qt 5.9

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Rafael
> Roquetto
> Sent: keskiviikkona 23. marraskuuta 2016 13.37
> To: Jani Heikkinen 
> Cc: development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Development] Qt 5.9
> 
> Hello,
> 
> On Tue, Nov 22, 2016 at 11:42:52AM +, Jani Heikkinen wrote:
> > Hi all,
> 
> > - Start supporting QNX 7.0
> 
> Has the QtC already laid out a plan for what needs to be considered for this? 
> I
> intend to start looking into it soon, but it would be best if we coordinated 
> this
> together in order to avoid duplicated efforts. In particular, we also want to
> properly support QNX 7 on QtCreator, which is orthogonal to having QNX 7
> support on Qt 5.9, timing wise it makes sense.
> 

To some extent, yes. Having proper c++11 support QNX 7 actually makes some 
things easier, while of course we still need to support QNX 6.6 as well. One of 
the first steps is to add QNX 7 to Qt CI system for dev and 5.9 - at least for 
build testing.

There will be many items to tweak and polish, and hope is that you and James 
will participate actively, as discussed at QtCon.

I am well aware the Qt release cycle is a bit quick to keep up with, but hope 
is we will be able to have good support for new QNX 7 already with Qt 5.9.

Yours,

Tuukka

> Thanks,
> Rafael
> 
> --
> Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-
> 563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL
> Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Proposal to adjust release candidate process

[Tuukka Turunen]

Hi,

I think we have three major problems with our current release process regarding 
the release candidate phase:

1.   Process to make a RC that is as flawless as final causes inefficiency 
as we only get full test coverage with the RC itself

2.   We get full attention for testing a bit too late, many fixes are still 
coming in close to the planned RC time causing instability

3.   Current time between RC and final is planned to be 2 weeks, which is 
very little in order to take in the feedback and fix things

Therefore, I would like to propose the following:

a.   Consider "Release Candidate" to be a phase rather than an individual 
delivery

b.   Create the first "RC1" almost immediately after release branch (e.g. 
5.9.0) is operational

c.   Criteria for the "RC1" is that no known P0 bugs exist (i.e. there can 
be other issues that would not be acceptable in a final release)

d.   During the "RC" phase P1 (and possible P0 of course) bugs and 
documentation are fixed

e.   Public "RC" release is similar development release as Alpha and Beta 
in that it starts a phase of work

f.Multiple snapshots / new candidates are created during the "RC" phase 
until one of them is considered the final release

If desired, we could use some other name than "Release Candidate 1" for the 
release that begins the last phase of the release. It could be called "Beta 2" 
or "Technology preview", if so desired. Personally, I would call it "Release 
Candidate 1".

The difference to our current process is quite small. In essence it would be 
about considering the "RC1" the beginning of the final releasing phase (.0 
branch), not something we do almost at the end of it. I believe that lowering 
the quality criterial for "RC1" helps us in being more efficient as it has been 
in practice impossible to really fulfill the current process goal and have 
already the first RC as good as the final.

In case of Qt 5.9 it would mean that we have the first "RC" out around end of 
April, soon after the branching to 5.9.0 has been completed. We then have 4 or 
so weeks to make all the needed amount of candidates / snapshots until one of 
them will be released as Qt 5.9.0 final. If it happens earlier than in 4 weeks, 
great. If it takes more time, then so be it (although in such case we have 
probably missed something in the earlier steps of the release creation).

Yours,

---
Tuukka Turunen
Director, R&D

The Qt Company
Lutakonaukio 1
40100 Jyväskylä, Finland
tuukka.turu...@qt.io
+358 40 7655 800
http://qt.io
---

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

Re: [Development] Proposal to adjust release candidate process

[Tuukka Turunen]

> -Original Message-
> From: sean.harmer On Behalf Of Sean Harmer
> Sent: tiistaina 20. joulukuuta 2016 17.14
> To: development@qt-project.org
> Cc: Tuukka Turunen ; releas...@qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> Hi Tuukka,
> 
> I agree with your proposal, however I think there is also another issue or two
> that we should address.
> 
> At present we have ~ 4 releases per year 2 minor versions and 2 further
> patch releases. One issue is that it looks like 5.8.0 will soon render the 
> very
> new
> 5.7.1 release redundant. With that in mind was it worth splitting the effort
> and having the 5.7.1 release at all? Don't get me wrong I'm all for additional
> patch releases just that I'd hope they wouldn't coincide so closely with a
> minor version release.
> 

Did we need Qt 5.7.1 in my opinion, yes we did. Was it too late, yes it was. We 
can not change the past, but for Qt 5.8, I would like to branch 5.8.1 quite 
soon after the 5.8.0 is released. This way there will be more time between 
5.8.1 and 5.9.0 releases. There are already quite many changes in 5.8 branch 
that are not in 5.8.0 branch.

> This brings me onto another issue which perhaps we feel more strongly than
> average in Qt 3D as a new module that is undergoing rapid bug-fixing,
> improvements and with lots of new feature development starting to open
> up. For example, although Qt 3D in Qt 5.7.0 was a nice release after lots of
> effort, we still fixed a huge number of issues for 5.7.1, which took 181 days 
> to
> release from 5.7.0.
> 
> Would it be possible for us to release more frequent patch releases? If not
> for the whole of Qt, then at least for addon modules such as Qt 3D? 

I would like to have more patch level releases. Perhaps not between the feature 
releases, but to continue patch releases of Qt 5.x also after 5.x+1 is 
released. Currently this has not been feasible, but it is something I am 
interested in for 5.9 (after we have completed the big CI HW and virtualization 
infrastructure change and relocated the machine room).

>The
> latter would require splitting the packaging of such modules but would
> reduce the amount of overall testing required for a new patch release. If
> we'd collectively rather not go down that street I still think more frequent
> patch releases would be nice. Users have the option of upgrading or not if
> they want to reduce their own internal regression testing burden and freeze
> on a specific version. But it would have the benefit that other users don't
> need to wait 6 months for a set of bug fixes - roughly the same time to wait
> as for new features.
> 
> I wonder how much of the current pressure on releases is driven by the
> time- based release policy. We aim for a new minor release every 6 months
> which is admirable. But I wonder about the consequences of trying to stick to
> that at the expense of quality of the 5.x.0 releases, especially given the 
> long
> turn around for subsequent patch releases.
> 

I think the two biggest reasons to the pressure are: 1. We end of having too 
big amount of changes in a patch release and 2. Test automation does not yet 
catch enough issues on embedded and mobile, and we need to use slow manual 
testing a lot.

Number #1 is something we can fix by our processes and behavior. It is also a 
"self filling prophecy" as we try to push a lot of things in to current release 
because it may take long time before next patch release is coming - thus making 
it more difficult to make patch releases. 

Number #2 is a continuous effort by our release and QA team and we are already 
quite good on desktop for automated package testing.

> With the above in mind, how about this proposal in addition to yours
> regarding the RC phase?
> 
> * Branch off new feature branch every 6 months as at present.
> 
> * Do not rush the release at the expense of quality or when it's convenient
> due to packagers going on vacation etc. We release only when the release is
> deemed to meet quality standards.
> 

We already try not to rush on expense of quality. I do think the current ~17 
weeks is too long time. It may be so long already that some lose focus. I would 
like to get it shorter, 10 or 12 weeks would be good in my opinion. The first 
step to reach this is to keep the feature freeze (no exceptions to complete 
some feature weeks after the FF).

> * Aim for a patch release every alternate month if there are fixes on the
> minor version branch and packaging/release staff are available. i.e. don't try
> to force one out before the summer/Xmas vacations.
> 
> * Consider releasing at least one patch release of the previous minor series
> after the release of the next minor series

Re: [Development] Proposal to adjust release candidate process

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Shawn
> Rutledge
> Sent: torstaina 22. joulukuuta 2016 9.25
> To: development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> 
> > On 22 Dec 2016, at 08:09, Maurice Kalinowski 
> wrote:
> >
> > Hence,
> >
> > Technology Preview
> > Preview
> > Release Preview
> > Release Candidate
> > Release
> 
> Tech Preview is so far the term for a module which is released but we
> reserve the right to continue making API changes anyway, right?  So changing
> that might be confusing.
> 
> And besides, alpha and beta are traditional and well understood.  (Following
> that pattern though, I guess we ought to call the RC a “gamma”, but that’s
> not traditional for some reason.)
> 

:)

If we do not want to call the first development release from the release branch 
"Release Candidate 1", then I think calling it "Release Preview" is a good 
approach.

Yours,

Tuukka

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: torstaina 22. joulukuuta 2016 22.09
> To: development@qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> Em quinta-feira, 22 de dezembro de 2016, às 12:54:08 BRST, Tuukka Turunen
> escreveu:
> > > And besides, alpha and beta are traditional and well understood.
> > > (Following that pattern though, I guess we ought to call the RC a
> > > “gamma”, but that’s not traditional for some reason.)
> >
> >
> >
> > If we do not want to call the first development release from the
> > release branch "Release Candidate 1", then I think calling it "Release
> > Preview" is a good approach.
> 
> Call it beta 2 (or gamma 1) right after branch and one we've iterated and we
> could have released, we call it release candidate. We release them more
> often, with more iterations, so that we get more feedback. I think that's the
> most important part.
> 

Beta 2 is still a bit misleading in my opinion. It is coming from release 
branch, so we are beyond the Beta phase.  Let's think about the name later, 
after the holidays. It anyway seems that the basic approach is seen viable. 

I would like to try this with Qt 5.9. The current scheduling lists the RC for 
17th of May. What would then be the anticipated time to release the 
gamma/beta2/preview release as soon as we are in the 5.9.0 branch? Perhaps 
around 3rd of May?

Yours,

Tuukka

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Robin Burchell
> Sent: perjantaina 23. joulukuuta 2016 3.40
> To: development@qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> My (slightly delayed) $0.02:
> 
> On releasing in general: I would agree that releases take too long, often, 
> but I
> am of the belief that a good part of this is a mess of our own making. For
> instance, due to an end-user or project requiring a specific version or purely
> out of fear that the next release may be a long time away, I think we
> (collectively) often end up pushing changes to branches that might be less
> than ideally suited for the change in question.
> 

I think this is true and something we need to address. Another symptom of this 
is the time we reserve between feature freeze and Alpha. Why does it always 
take many weeks (4 is reserved in the current release process 
http://wiki.qt.io/Qt5Releasing). There is still a lot of commits coming during 
this phase, perhaps some of them are such that actually should have been in 
before the FF. I would like us to reach a state where Alpha is released almost 
immediately (within 1 week) of the Feature freeze. I know that we are not yet 
there, but in order to reduce the overall release time that is necessary. 

> I think we should recognise that these pressures do exist, and consider ways
> we can work to mitigate them (things like: nightly or at least semi-"nightly"
> builds? working on pushing out patch releases more often?
> encouraging more of our consumers to apply patches that we already took in
> upstream and do their own builds? anything else?)
> 
> It goes without saying that these are hard problems, but I think that working
> at the root causes is the only way to ultimately fix this.
> Moving away from a time-based schedule is just going to encourage the
> schedule to slip further, because now you have to wait [potentially forever]
> to get a change released rather than roughly [x months], which leads to even
> more pressure to get changes in an earlier version.
> 

We do not want to move away from the time based releasing, just trying to 
become better in 1. keeping the schedule and after that 2. reducing the time it 
takes to make a feature release of Qt.

> Ultimately, I think we need to be better at saying "no" to changes that aren't
> explicitly necessary, especially on version branches (5.x.y) and in general
> taking care to evaluate how "done" something is before taking it in too. This
> is not an exact science, though, which makes it difficult to balance. Even if 
> we
> truly are on the side of being too aggressive now - it may be perfectly
> possible that we could end up too conservative (and delaying fixes that our
> end users would like to see sooner), e.g. by implementing some kind of
> "blanket" restriction like "only P0 bugs get fixed in this branch" (not a
> suggestion I am making I will emphasise, just a note that we need to
> approach this carefully).
> 

This, I think, especially has been an issue with some of our patch level 
releases lately. While it sounds good to have fixes, too big amount of fixes is 
prone to cause instability - and certainly it increases the effort of making 
the patch releases.

> To the proposal at hand: I think that we should not be afraid of releasing
> more release candidates. Some of them may well be broken, and while that's
> unfortunate, it's still certainly better that we release broken release
> candidates than a broken final release in the end.
> 

Thanks, fully agree. Our users are intelligent people. I do not think anyone 
thinks such an early preview releases can be used in production (or if they 
would, then there is a good reason).

> It may be the case that releasing more betas or using a different name may
> help get feedback earlier, but IMHO we have to accept to some extent that
> our end users are not us: they have limited time to build & test Qt in 
> addition
> to their normal product/application work, and thus, overall, we should not
> expect too much of them. If we want more feedback, we need to work on
> making that testing process easier for them, rather than playing naming
> tricks, I think.
> 

Actually the problem currently has not so much been lack of feedback, but the 
fact that feedback comes so late in the release phase that it is hard to react 
to it properly. I hope we could slightly ease this by having the first release 
from release branch earlier than we now do. 

Yours,

Tuukka

> On Tue, Dec 20, 2016, at 02:34 PM, Tuukka Turunen wrote:
> >
> > Hi,
> >
> > I think we have three

Re: [Development] Proposal to adjust release candidate process

[Tuukka Turunen]

Hi,

Perhaps it is best to talk with marketing about the name of the "release done 
immediately after branching to the .0 release branch". Reading the discussion, 
it seems that other than the name we are well aligned.

Our current process has "Release candidate" 2 weeks prior to the Final release 
(see: https://wiki.qt.io/Qt5Releasing).

If we now have the beta2/preview/othername release 4 weeks before the final, 
our schedule is the following:

Phase  Timing
Feature freezeT-17 weeks
Alpha release  T-13 weeks
Beta release T-8 weeks
Soft string freeze   T-6 weeks
Hard string freeze T-5 weeks
Beta2/Preview/XYZ  T-4 weeks
Final releaseT

In addition to the main phases, there will be snapshots regularly for testing. 
During the final weeks before the release these snapshots are then considered 
as possible final release unless testing reveals a need to change something. 
This part is unchanged.

The main benefit for the change is providing a very close to final package for 
users to test earlier. During the 4 weeks after Beta there is always a lot of 
improvements, but after branching to the release branch we should focus only 
for the high-priority error corrections and polishing the documentation (if not 
already done earlier).

PS. I would like to shorten the overall duration of the release creation to 12 
weeks from FF to final. I think that being more strict about the FF and by 
having all the needed configurations done early enough, we should be able to 
cut the time between FF and Alpha as well as between Alpha and Beta. But that 
is something we can discuss later.

Yours,

 Tuukka


From: Development 
[mailto:development-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of 
Simon Hausmann
Sent: perjantaina 23. joulukuuta 2016 19.02
To: Thiago Macieira ; development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process




Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case 
the branch makes no difference and beta is a better name.





Simon


From: Development 
mailto:development-bounces+simon.hausmann=qt...@qt-project.org>>
 on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Sent: Friday, December 23, 2016 4:42:12 PM
To: development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process

Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
escreveu:
> I find that the branch is relevant in this context, as it relates to the
> amount of patches going in. The amount of patches going in is IMO related
> to the probably of introducing regressions. The process around the release
> branch, as opposed to the "minor branch", as proven to be a useful
> mechanism for reducing the churn and making people ask themselves: Do I
> really want this change in this release or can it wait?
>
> So from what I think is one metric of quality (not the only one of course),
> the naming of release candidate is more meaningful.

How about this, then? We release beta2 from the 5.n branch right before the
5.n.0 branch is created (or finally branches off). It accomplishes the same
thing that Tuukka wanted: a release containing the code that is in the 5.n.0
branch at the moment it is created, not a few weeks after with some round of
work.

And I really mean "the code that is in the 5.n.0 branch". Since the two
branches at the same at that point, it's only a semantic difference which one
we created the beta2 release from.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Oswald
> Buddenhagen
> Sent: keskiviikkona 11. tammikuuta 2017 18.50
> To: development@qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 
> > I don’t want to miss the deadline for feature freeze, so I’m hoping to
> > get past that hurdle and address some of your proposals afterwards as
> > a tech preview.
> >
> that seems a bit optimistic, given that we're discussing some rather
> fundamental aspects of the design.
> 
> also, i don't think we've been bothering a lot about deadlines for TP modules,
> so who cares.
> 

As this is a module to be added, we need to have it in place latest at the FF. 
Preferably modules should be in place earlier than FF.

The criteria for the content of the module is of course less strict when it is 
a TP, but still if it is likely to need full refactoring perhaps waiting for 
5.10 is a better option?

Yours,

Tuukka

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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: torstaina 12. tammikuuta 2017 3.19
> To: development@qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 
> On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen"
>  oswald.buddenha...@qt.io> wrote:
> 
> 
> 
> >also, i don't think we've been bothering a lot about deadlines for TP
> >modules, so who cares.
> 
> Apparently Tuukka does, since he’s suggesting holding off until 5.10...
> 
> >it doesn't help that you apparently haven't even explored the prior art
> >within qt even though it was pointed out to you two years ago already.
> 

Yes, when it comes to being part of a "release train" the cargo needs to be in 
decent shape when the trains leaves the station.

I would like to emphasize that I have nothing against this module being part of 
Qt 5.9 as a TP - as long as it is in such shape that causes no harm to the Qt 
5.9 release schedule.

Many of the delays we have had with previous Qt 5 releases have been partially 
caused by not being ready at the FF time. 

Yours,

Tuukka

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

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: keskiviikkona 18. tammikuuta 2017 4.52
> To: Oswald Buddenhagen ;
> development@qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 

...

> 
> For providing Qt new functionality, I feel the existing QtRO design is sound.
> If at some point #1 becomes a reality, I would be glad to revisit a generic 
> idl.
> 

When QtRO becomes part of Qt, would you continue as the maintainer of the 
module and have adequate time to polish it so that it can be fully supported in 
the upcoming Qt releases?

Yours,

Tuukka


> Regards,
> Brett
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Stottlemyer,
> Brett (B.S.)
> Sent: keskiviikkona 18. tammikuuta 2017 15.50
> To: development@qt-project.org
> Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for
> Qt 5.9
> 
> On 1/18/17, 1:52 AM, "Tuukka Turunen"  wrote:
> 
> 
> >>
> >
> >When QtRO becomes part of Qt, would you continue as the maintainer of
> the module and have adequate time to polish it so that it can be fully
> supported in the upcoming Qt releases?
> >
> >Yours,
> >
> > Tuukka
> 
> Sure, that is the plan.  That does however tie into a question I had.  Would
> my Maintainer status for the playground project automatically carry forward?
> Or will I lose my approver rights once it moves into Qt?  I understand
> Approver rights are not granted lightly, while it is also very difficult to
> maintain a module without being able to +2 reviews.
> 
> What has happened in the past?
> 

Hi,

Unless someone objects and proposes a better maintainer (which is quite unlike 
as you are the main author), you would continue as the maintainer of the module.

Yours,

Tuukka

> Regards,
> Brett
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominate Mike Krus as approver

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: maanantaina 6. helmikuuta 2017 20.27
> To: development@qt-project.org
> Subject: Re: [Development] Nominate Mike Krus as approver
> 
> On segunda-feira, 6 de fevereiro de 2017 18:39:19 PST Oswald Buddenhagen
> wrote:
> > On Mon, Feb 06, 2017 at 02:54:53PM +, Alexander Blasche wrote:
> > > >There were no objections and maintainer of a module implies
> > > >approver, so could somebody do the honours and grant Mike the
> > > >rights please? The necessary period has long since passed.
> > >
> > > I am sorry but being the maintainer does not imply approver rights.
> > > At most it implies approver rights for the component he is
> > > maintainer for. I agree that when you maintain a cross module
> > > component that this is somewhat harder to manage.
> > selective approver rights are not implementable for a horizontal
> > responsibility, so this is kind of moot.
> >
> > > In any case I am sure that waiting for the required time does not
> > > make much of a difference. Then this discussion is over anyway.
> > the previous thread already used the word approver without futher
> > qualification
> > (http://lists.qt-project.org/pipermail/development/2016-August/026909.
> > html) and nobody objected, so i just gave mike the rights.
> 
> Let's not quabble over this.
> 
> Becoming maintainer of anything in a main module implies becoming
> Approver everywhere, if one is not so yet.
> 

+1

(to me this has mostly already been the case, but as it seems to be unclear it 
is good to document it clearly)

> Restricted maintainership rights should be used only for playground things.
> 

+1

(barrier to have playground repo should be low, thus these could be maintained 
by persons who are not approvers yet)

Yours,

Tuukka

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

Hi,

Short summary: The Qt Company has decided to focus development effort to 5.9 
and dev branches in order to reach the planned timeline for Qt 5.9 release and 
make improvements in the CI system. Next scheduled patch level release would be 
Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security vulnerability 
we would make Qt 5.8.1 directly based on 5.8.0 with just the security fix(es) 
added.

Qt 5.8.0 looks to be a good and successful release. It has already been 
downloaded 150.000 times even though it was released just two weeks ago. The 
reception has been good overall and there are no blockers reported based on the 
release. Qt 5.9 and subsequent releases will leverage the new configuration 
system and other major improvements introduced with it, as well as add new 
functionality to make Qt even better.

It took us a more time than planned to get Qt 5.8 out and because of that we 
are already past Qt 5.9 feature freeze and approaching the alpha release soon. 
Looking into the reasons why Qt 5.8.0 was delayed there are 3 items that had a 
significant effect:
1. We did not keep the feature freeze properly as there were some items we 
wanted to get in – doing so we should have replanned the whole release time, 
but we tried to keep schedule and failed.
2. We were not able to focus enough to Qt 5.8 finalization as there was quite a 
lot of effort going still to Qt 5.6.x and 5.7.x patch releases in parallel – 
and our systems and processes are not yet good enough for this.
3. We have had some issues in the CI system that cause integrations to fail and 
thus increase system load – these are now being addressed (getting new HW in 
place, change to a better virtualization platform, use local disks instead of 
central disk, reduce number of flaky tests, etc).

We believe it will be possible to significantly reduce the time from feature 
freeze to release. To reach this we need to improve the items that have been 
problematic with Qt 5.8 and other releases. After we have done the 
improvements, it will be easier to keep the timelines and also be more 
productive. We absolutely do not want to rush a new release out with severe 
bugs in it – not now and not in the future – for this reason we want to focus 
into the processes and systems part and allow more efficient release creation. 
First we want to be able to reach the current 17 weeks timeline from FF to 
release with Qt 5.9. After that we want to reduce it gradually to 10-12 weeks 
(for a new minor release of Qt). Increased productivity will allow us to make 
more patch releases than before.

In the CI system side we have major improvements happening during this year. We 
will be purchasing more blades and other HW during H1/17, which will add 
capacity, so we will be able to run more parallel integrations. We are also 
looking into changing the system architecture away from central disk into using 
local ssd for build machines. This is expected to bring improvements to both 
performance and reliability (especially now as we have had issues with disks 
failing despite the disk system still being in the mid of its life-cycle). 
Third item we are looking into is change of the virtualization platform, which 
we hope will bring improvements in stability as well as new capabilities.

Arranging enough time to implement the improvements in our systems as well as 
keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately means 
that we can’t make any scheduled patch releases until June, after Qt 5.9 is 
out. We will keep the ability to release patch release for urgent security 
vulnerabilities, as always. Such release would be on top of the previous patch 
release and not include all other changes in the corresponding branch. Even 
with a lot more help from community than before, making a scheduled Qt 5.8.1 
release parallel with Qt 5.9 has impact to the system load as well as to the 
work needed from the release team and others.

I am well aware that a Qt 5.8.1 release would be beneficial, but making one now 
would impact Qt 5.9 schedule and our capability to improve CI system stability. 
Qt 5.6.3 LTS patch release is done straight after Qt 5.9 release, but not 
before. After the Qt 5.9.0 in May we should then focus into making Qt 5.9.1 
release instead of making Qt 5.8.1 any more as Qt 5.9.0 is already out. With 
the CI improvements in place, we should definitely be able to make more than 
one patch release for Qt 5.9.

As a scheduled Qt 5.8.1 release is not planned, should we start pushing fixes 
directly to 5.9 branch now? It would reduce the workload as we do not need to 
first integrate changes into 5.8 and then merge upwards to 5.9. It would also 
reduce the time it takes to get fixes into to 5.9 and dev as well as reduce the 
load to the CI system as less integrations are needed. We can keep 5.8 branch 
open for a while still similarly as 5.6 is in case there is some fix that must 
be in the 5.8 branch. Let’s discuss in the nex

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

 have a bug fix release. Are there really 
features in 5.9 that customers cannot live without for an extra 4-6 weeks 
whilst we prepare a 5.8.1 release? I very much doubt it.

Kind regards,

Sean

On Friday 10 February 2017 10:59:56 Tuukka Turunen wrote:
> Hi,
> 
> Short summary: The Qt Company has decided to focus development effort to 
5.9
> and dev branches in order to reach the planned timeline for Qt 5.9 release
> and make improvements in the CI system. Next scheduled patch level release
> would be Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security
> vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with just the
> security fix(es) added.
 
> Qt 5.8.0 looks to be a good and successful release. It has already been
> downloaded 150.000 times even though it was released just two weeks ago.
> The reception has been good overall and there are no blockers reported
> based on the release. Qt 5.9 and subsequent releases will leverage the new
> configuration system and other major improvements introduced with it, as
> well as add new functionality to make Qt even better.
 
> It took us a more time than planned to get Qt 5.8 out and because of that 
we
> are already past Qt 5.9 feature freeze and approaching the alpha release
> soon. Looking into the reasons why Qt 5.8.0 was delayed there are 3 items
> that had a significant effect:
 1. We did not keep the feature freeze
> properly as there were some items we wanted to get in – doing so we should
> have replanned the whole release time, but we tried to keep schedule and
> failed. 2. We were not able to focus enough to Qt 5.8 finalization as 
there
> was quite a lot of effort going still to Qt 5.6.x and 5.7.x patch releases
> in parallel – and our systems and processes are not yet good enough for
> this. 3. We have had some issues in the CI system that cause integrations
> to fail and thus increase system load – these are now being addressed
> (getting new HW in place, change to a better virtualization platform, use
> local disks instead of central disk, reduce number of flaky tests, etc). 
> We believe it will be possible to significantly reduce the time from 
feature
> freeze to release. To reach this we need to improve the items that have
> been problematic with Qt 5.8 and other releases. After we have done the
> improvements, it will be easier to keep the timelines and also be more
> productive. We absolutely do not want to rush a new release out with 
severe
> bugs in it – not now and not in the future – for this reason we want to
> focus into the processes and systems part and allow more efficient release
> creation. First we want to be able to reach the current 17 weeks timeline
> from FF to release with Qt 5.9. After that we want to reduce it gradually
> to 10-12 weeks (for a new minor release of Qt). Increased productivity 
will
> allow us to make more patch releases than before.
 
> In the CI system side we have major improvements happening during this 
year.
> We will be purchasing more blades and other HW during H1/17, which will 
add
> capacity, so we will be able to run more parallel integrations. We are 
also
> looking into changing the system architecture away from central disk into
> using local ssd for build machines. This is expected to bring improvements
> to both performance and reliability (especially now as we have had issues
> with disks failing despite the disk system still being in the mid of its
> life-cycle). Third item we are looking into is change of the 
virtualization
> platform, which we hope will bring improvements in stability as well as 
new
> capabilities.
 
> Arranging enough time to implement the improvements in our systems as well
> as keeping the timeline of Qt 5.9 despite delayed 5.8 release 
unfortunately
> means that we can’t make any scheduled patch releases until June, after Qt
> 5.9 is out. We will keep the ability to release patch release for urgent
> security vulnerabilities, as always. Such release would be on top of the
> previous patch release and not include all other changes in the
> corresponding branch. Even with a lot more help from community than 
before,
> making a scheduled Qt 5.8.1 release parallel with Qt 5.9 has impact to the
> system load as well as to the work needed from the release team and
> others.
 
> I am well aware that a Qt 5.8.1 release would be beneficial, but making 
one
> now would impact Qt 5.9 schedule and our capability to improve CI system
> stability. Qt 5.6.3 LTS patch release i

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

Hi Sean,

I do appreciate the offer to help with Qt 5.8.1 creation, but as I explained in 
my email to the ml yesterday, I do not think it is feasible plan to make a 
release without involving several people from The Qt Company for it and also 
causing a load to CI hindering development of 5.9 in parallel. Unfortunately 
making a new Qt release is so complicated due to large amount of platforms and 
packages involved, that it mandates effort of releasing team of The Qt Company 
as well as many developers. 

As I explained yesterday, even with a lot of help it would mean that 5.9.0 
happens probably end of June or beginning of July. This would mean we lose the 
opportunity window to catch up with releasing and improve the CI system 
(because Finland and Norway mostly are off in July and Germany in August). 
Doing the CI change after August means we are already close to 5.10 release.

As multiple people and teams have planned their development according to 
initially agreed feature freeze time of Qt 5.9, it would be very inefficient to 
reopen 5.9 now or postpone getting the release out. 

If we can get KDAB and others helping with Qt 5.9 with even remotely similar 
effort than it would be to create Qt 5.8.1 release I am sure we can make an 
awesome Qt 5.9.0 ahead of the planned schedule. This means we can make the CI 
system improvements earlier and thus also have Qt 5.9.1 earlier.

Yours,

Tuukka 

On 16/02/2017, 11.14, "Development on behalf of Sean Harmer" 
 wrote:

On Wednesday 15 February 2017 18:17:32 Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2017 09:00:09 PST Tuukka Turunen 
wrote:
> > First I want to say that I am also very sorry that we need to skip 
5.8.1.
> > Unfortunately I do not see any other approach that would allow us to: 1)
> > catch the delay caused by 5.8 being late (and 5.7 being late, and 5.6
> > being
> > late) and 2) enable implementation the much needed CI changes in good 
time
> > before Qt 5.10 feature freeze.
> 
> Here's a way:
> 
> Push the 5.9 and 5.10 timelines back. If necessary, unfreeze Qt 5.9.

Yes this is what I would vote for too. The 5.9 deadline is somewhat 
arbitrary/self imposed so does not have to be set in stone. If this has 
knock-
on effects for the CI upgrades, why can't these be done during the summer 
break by staggering the sysadmin vacations instead of all of them going off 
at 
the same time?

With this we could have a timeline something like this:

1) Release 5.8.1 asap. Hopefully this would go smoothly given it's a .1 
release.
2) Push 5.9.0 deadline to end of June but aim for earlier if the config 
system 
doesn't adversely affect the package generation.
3) Perform CI upgrades as soon as 5.9.0 is out (may require some juggling 
of 
vacation requests if 5.9.0 goes until end of June.
4) After summer vacation, start release process for 5.9.1 and 5.10.

This also helps mitigate the risk of something delaying the 5.9.0 release 
by 
getting a .1 release to the users in the interim.

Also, to allow others to help with the release process, could you explain 
where the main bottle neck is with the release process please? Is it the 
package generation itself? The smoke testing? Something else?

KDAB is willing to help where we can if it means we can get a 5.8.1 release 
in 
the hands of yours and our customers. But to be able to help, we need to 
know 
how we can.

Kind regards,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

From: Development  on 
behalf of Roland Winklmeier 
Date: Friday, 17 February 2017 at 12.20
To: "development@qt-project.org" 
Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch releases 
during H1/17

Hi Tuukka,

2017-02-16 17:13 GMT+01:00 Tuukka Turunen 
mailto:tuukka.turu...@qt.io>>:
As multiple people and teams have planned their development according to 
initially agreed feature freeze time of Qt 5.9, it would be very inefficient to 
reopen 5.9 now or postpone getting the release out.

I would use the same argument for all customers and users of Qt who planned 
their development on a 5.8.1 release, but with my argument that a bug fix 
release should have priority over a new feature release.


If we can get KDAB and others helping with Qt 5.9 with even remotely similar 
effort than it would be to create Qt 5.8.1 release I am sure we can make an 
awesome Qt 5.9.0 ahead of the planned schedule. This means we can make the CI 
system improvements earlier and thus also have Qt 5.9.1 earlier.

My question might sound sarcastic but it is really serious: Who does guarantee 
me that a 5.9.1 release won't be dropped again in favor of the 5.10 release 
schedule? Maybe I'm not familiar with the process and details how and when a 
decision for a patch release is made, but I learned from this discussions that 
it was expected by most people. If there is no guarantee in the future, this 
decreases dramatically my will to test and fix bugs after a .0 release in this 
branch. My contribution might not be high and in total insignificant though.
This is a valid concern. I can assure you that The Qt Company has nothing 
against patch releases. You can look back in history and see that we do make 
patch releases, sometimes quite many of them. But lately it has become harder 
and harder. Now we want to fix the fundamentals and get back to normal mode of 
operations with Qt 5.9, including making patch releases.
Yours,
Tuukka

I can only repeat my personal opinion: Bug fixes first, then new features. If 
the time between two feature releases is too close, then increase the time or 
change to a release-when-its-ready timeline.
My 2 cts.

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

>On 18/02/2017, 21.40, "Development on behalf of Thiago Macieira" 
>thiago.macie...@intel.com> wrote:
>
>On sábado, 18 de fevereiro de 2017 12:11:53 PST Mat Sutcliffe wrote:
>> On 18 February 2017 at 19:13, Thiago Macieira 
>> My point was that this decision happened already on 29 November. That was
>> the original planned release date for 5.8.0, and also the day on which 
> the
>> 5.9.0 initial schedule was set. Could it have been predicted at that time
>> what the consequences might be for 5.8.1?
>
>Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda.
>
>The question is only what to do now.

What I hope we can do is to have everyone helping to get Qt 5.9.0 out as soon 
as possible and then make also 5.9.1 soon (although I think we do need to make 
5.6.3 in between).

If we can have the extra help proposed by KDAB and others in the community for 
making Qt 5.8.1 release geared towards making Qt 5.9 we will be able to make it 
faster and with higher quality than otherwise possible. 

One concrete item is manual testing of our various snapshots. The sooner these 
are fully tested, the better. We have CI and RTA test automation, but these do 
not cover every aspect. Manual testing is needed as well. Often it is a case 
that a bug is found in quite late release steps, but has actually been there 
for some time already. Another way to help is making good bug reports that are 
also notified to the release team. The better the description of the issue, the 
easier it is to fix it. Third item is of course fixing things quickly – by 
having more people fixing the issues identified we will be able to close them 
sooner and thus proceed faster. 

For the CI stability most important thing is to reduce the amount of flaky test 
cases, which cause failures in CI runs. This in turn both adds delay as well as 
increases the load of the CI. 

Yours,

Tuukka

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

Hi Kevin,

As has been said many times, features of Qt 5.9 have already been developed and 
frozen, development of Qt 5.10 features is ongoing. Postponing or reopening Qt 
5.9 would mean we work very inefficiently and that should be avoided. There are 
also many other reasons, as I have explained in multiple mails to the mailing 
lists. No-one likes skipping patch level releases, but this is what now needs 
to be done. Qt 5.7.1 has been released in December and Qt 5.8.0 in January – so 
we do have very recent two releases you and others to use. 

What comes to Open Governance, we of course can always improve communications. 
What was done is that I informed decision that The Qt Company had done not to 
participate in making Qt 5.8.1 release and based on that the Release team of 
the Qt Project decided to close Qt 5.8 branch. Some people volunteered to help 
in making Qt 5.8.1, which is great but... the current infrastructure does not 
enable making a new patch release without a significant effort from The Qt 
Company personnel as well as a major load in the systems. Therefore, I have 
proposed that we all rather focus on getting Qt 5.9.0 and 5.9.1 out faster and 
improve the stability of the infrastructure (including fixing the flaky test 
cases).

We have many users still in Qt 5.6 LTS, which is fine, but eventually we need 
to provide new releases that receive more than one patch level release. 
Hopefully we can do this for Qt 5.9 with the new CI system infrastructure 
coming around June timeframe as well as the improve stability of the system 
achieved via fixing the flaky cases. 

Yours,

Tuukka

On 04/03/2017, 0.56, "Development on behalf of Kevin Kofler" 
 wrote:

Mathias Hasselmann wrote:
> Guys, by not delivering bugfix releases for arbitrary reasons we are
> risking to kill Qt's credibility as reliable toolkit. Our users trust in
> getting bugfix releases.

I agree with this. I really don't see why you don't postpone 5.9 instead. 
Qt 
used to release on a 9 to 12 month basis, now it is down to 6 months. And 
for 5.9, not even that, because somehow there is an unrealistic expectation 
that 5.9 magically makes up for the delays in releasing 5.8. The release 
schedule for 5.9 should be based on the actual 5.8 release date, not the 
planned 5.8 release date. The amount of churn is such that some distros are 
still working on packaging 5.8 while you are already about to branch 5.9.

I also agree with Marc Mutz (and no, you have not misread ;-) ) that the 
way 
the decision is being dictated onto the community runs counter to the "Open 
Governance" promises.

Kevin Kofler

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


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

Re: [Development] Proposal to adjust release candidate process

[Tuukka Turunen]

+1 from me to this improved approach

--
Tuukka 

On 27/03/2017, 12.40, "Development on behalf of Jani Heikkinen" 
 wrote:

Hi all,

Ok, I have thought this now a while & discussed internally with Tuukka and 
few others. I have new proposal which is kind of middle between Tuukka's 
proposal & current process:

1. From FF to beta we will do things as earlier. Of course we need to find 
ways to cut the time there but it is different story...
   - Only change is snapshot build distribution via online installer before 
beta release & beta release as online only (this is already implemented)
2. After first beta release we don't deliver any binary snapshots anymore 
but do release additional beta releases ~ once per week (with more lightweight 
process than current releases are done: no blog post from every beta release, 
limited test round before additional beta N release and full test round when 
beta N is publicly available, no official approval from release team meetings 
...)
   - This is mandatory step now when delivering snapshot & pre-releases via 
online installer: New snapshot / pre-releases are updates to previous one -> 
after beta2 is released there is no first beta available via online installer.
3. When beta N is well enough we will create and release RC.
4. If RC seems to be good enough we will release final but if some blocker 
found during RC testing we will release immediate RC2 (again with more 
lightweight process) etc..

br,
Jani
____
From: Development  
on behalf of Tuukka Turunen 
Sent: Tuesday, January 03, 2017 10:02 AM
To: Simon Hausmann; Thiago Macieira; development@qt-project.org; 
releas...@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process

Hi,

Perhaps it is best to talk with marketing about the name of the “release 
done immediately after branching to the .0 release branch”. Reading the 
discussion, it seems that other than the name we are well aligned.

Our current process has “Release candidate” 2 weeks prior to the Final 
release (see: https://wiki.qt.io/Qt5Releasing).

If we now have the beta2/preview/othername release 4 weeks before the 
final, our schedule is the following:

Phase  Timing
Feature freezeT-17 weeks
Alpha release  T-13 weeks
Beta release T-8 weeks
Soft string freeze   T-6 weeks
Hard string freeze T-5 weeks
Beta2/Preview/XYZ  T-4 weeks
Final releaseT

In addition to the main phases, there will be snapshots regularly for 
testing. During the final weeks before the release these snapshots are then 
considered as possible final release unless testing reveals a need to change 
something. This part is unchanged.

The main benefit for the change is providing a very close to final package 
for users to test earlier. During the 4 weeks after Beta there is always a lot 
of improvements, but after branching to the release branch we should focus only 
for the high-priority error corrections and polishing the documentation (if not 
already done earlier).

PS. I would like to shorten the overall duration of the release creation to 
12 weeks from FF to final. I think that being more strict about the FF and by 
having all the needed configurations done early enough, we should be able to 
cut the time between FF and Alpha as well as between Alpha and Beta. But that 
is something we can discuss later.

Yours,

 Tuukka


From: Development 
[mailto:development-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of 
Simon Hausmann
Sent: perjantaina 23. joulukuuta 2016 19.02
To: Thiago Macieira ; development@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process




Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that 
case the branch makes no difference and beta is a better name.





Simon


From: Development 
mailto:development-bounces+simon.hausmann=qt...@qt-project.org>>
 on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Sent: Friday, December 23, 2016 4:42:12 PM
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Proposal to adjust release candidate process

Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann
escreveu:
> I find that the branch is relevant in this context, as it relates to the
> amount of patches going in. The amount of patches

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

Hi,

With Qt 5.9 beta released last week, I think we should close 5.8 branch now. 

Closing 5.8 will help getting Qt 5.9 out in time by pushing everything directly 
into 5.9 branch. This is already the case for most items, but some items are 
still pushed to 5.8 branch causing the need for continuous merges and delaying 
getting those fixes to 5.9. Running the merges and submodule updates also 
causes load to the CI, which is away from doing more frequent runs on 5.9 and 
dev.

There has been a lot of discussion about this in the mailing lists, I think the 
two ones below sum it up quite well.

Yours,

Tuukka



On 13/03/2017, 13.33, "Development on behalf of Oswald Buddenhagen" 
 wrote:

On Wed, Mar 01, 2017 at 01:38:47PM +0100, Marc Mutz wrote:
> On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote:
> > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka
> > > proposed. After some thinking I also agree that this is the best
> > > course of action from where we are right now.
> > 
> > This also implies that bug fixes should now get pushed to the 5.9
> > branch and we should close the 5.8 branch soon.
> 
> I disagree. Even if you cannot produce releases from 5.8 anymore,
> that's our stable branch.
>
that may be the case, but doesn't necessarily mean that you need to
upstream your fixes there. closing it only affects other users of the
5.8 tip who want your fixes. probably not that many.

otoh, the branch being open costs CI cycles and causes some forward
merging effort, while benefitting a marginal number of people.

another point is that most tqtc employees are actually following the
management order and are neglecting 5.8 (for two months now), which
means that it's by far not as stable as one would want it to be.

so i guess it's time to give in and officially close the branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



On 01/03/2017, 21.58, "Development on behalf of Thiago Macieira" 
 wrote:

Em quarta-feira, 1 de março de 2017, às 04:38:47 PST, Marc Mutz escreveu:
> > This also implies that bug fixes should now get pushed to the 5.9 branch
> > and we should close the 5.8 branch soon.
> 
> I disagree. Even if you cannot produce releases from 5.8 anymore, that's 
our
> stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can
> close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6?

We usually switch the default branch between the beta and the RC, so the 
point 
is moot.

5.9 will be considered stable in a couple of weeks, so 5.8 can be closed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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


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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

Hi Marc,

I can understand your viewpoint, but unfortunately keeping 5.8 open does cause 
additional load to the systems as well as people. It would be great if you 
would rather focus into improving Qt 5.9 and making it good for our users than 
pushing stuff into a branch that has no further releases planned from it. 

Can you explain why you can not push your Qt Base changes to 5.9 like ~everyone 
else? 

Yours,

Tuukka
 

On 11/04/2017, 11.34, "Development on behalf of Ville Voutilainen" 
 wrote:

On 11 April 2017 at 11:22, Ville Voutilainen
 wrote:
> On 11 April 2017 at 10:30, Marc Mutz  wrote:
>> On Tuesday 11 April 2017 07:49:28 Tuukka Turunen wrote:
>>> There has been a lot of discussion about this in the mailing lists, I 
think
>>> the two ones below sum it up quite well.
>>
>> They sum up *your* POV well. But up to a few weeks ago, more fixes went 
into
>> 5.8 QtBase than changes into 5.9, even though TQC personell was asked to
>> ignore 5.8.
>>
>> You can close 5.8 on all other modules, if you wish, but I'd ask to keep 
it
>> open on QtBase, which has a lively development going on in 5.8 to this 
day.
>
>
> Here's an anecdote: this https://codereview.qt-project.org/#/c/189229/
> hasn't been merged
> to 5.9, as far as I can see. I find it curious that bugfixes from two
> weeks ago haven't trickled
> into 5.9 from 5.8 yet. Such matters may well raise the bar for users
> for working with 5.9 rather than
> with 5.8.

To elaborate: I run a bleeding-edge compiler. It feels odd to me that
the best branch to run it on
is a non-bleeding-edge branch, it's quite the opposite.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

Hi,

No-one should be pushing to 5.8 any more, but I know that some still do. 
Closing 5.8 means it is easier to push to the right branch. We have talked this 
already many times over. Keeping 5.8 open brings little value, but causes load 
to machines, additional work for people and delay in getting the fixes to users 
(as it is 5.9 where beta snapshots are created from).

For example, on March 1st Lars wrote: “Let’s conclude this topic now by moving 
on towards 5.9 as Tuukka proposed. After some thinking I also agree that this 
is the best course of action from where we are right now. This also implies 
that bug fixes should now get pushed to the 5.9 branch and we should close the 
5.8 branch soon.”

What I am now saying is that it is now time to do what has been discussed. We 
have Qt 5.9 beta out and there is constant focus in getting regular snapshots 
from 5.9. 

Yours,

Tuukka

On 11/04/2017, 12.00, "Development on behalf of Marc Mutz" 
 wrote:

On Tuesday 11 April 2017 10:47:52 Tuukka Turunen wrote:
> Can you explain why you can not push your Qt Base changes to 5.9 like
> ~everyone else? 

Because, at least in QtBase, everyone is pushing fixes to 5.8?

You saw Thiago's stats.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

Hi,

We have discussed this already multiple times and it is well known by everyone. 
Closing of the branch has been clearly decided, only item open has been the 
time. Now that we have 5.9 beta released, I think it clearly is the time to 
close 5.8 and fully focus into making Qt 5.9 good. The sooner we get 5.9.0 out, 
the sooner we can also get 5.9.1 out. And note that 5.9.0 contains every fix 
that would have been part of 5.8.1 and more – a lot more. 

No-one is happy about skipping patch releases for 5.8. This is a trade off done 
in order to get better Qt releases in the future. Keeping 5.8 branch open and 
pushing fixes there instead of 5.9 results in worse 5.9 than we could have by 
focusing to it. Every single merge from 5.8 to 5.9 is time away from people to 
work on 5.9 (and dev), from machines to be able to work on 5.9 (and dev), and 
from calendar time of having fixes on the hands of most of the users (i.e. 
getting them into a release of Qt or pre-releases of Qt).

Yours,

Tuukka

On 11/04/2017, 14.17, "Development on behalf of Giuseppe D'Angelo" 
 wrote:

Il 11/04/2017 12:46, Aleix Pol ha scritto:
> What's the point of keeping 5.8 open if there's not going to be
> another 5.8 release?

Because of customer projects, Linux distributions, etc. that are
currently on 5.8, and that want to benefit from the latest bug fixes and
performance improvements without waiting 4-5 months for 5.9.1.

Yes, they *will* skip any .0 release, and convincing customers to
upgrade to a new minor release is definitely more complicated than
convincing to upgrade to a new patch release (... which in this case
translates to tracking the 5.8 branch).

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts



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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

> On 11/04/2017, 14.43, "Konstantin Tokarev"  wrote:
>
>   Maybe it's plausible to make 5.8.1 release just for QtBase?

No. That is not possible. This has also been discussed before.

There is still a lot of work left to do for getting Qt 5.9 ready. That is what 
we should focus into as that is what benefits Qt the best overall. We need to 
provide a solid release that receives multiple patch releases. 

Yours,

Tuukka

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Tuukka Turunen]

> On 11/04/2017, 16.09, "Stottlemyer, Brett (B.S.)"  wrote:
>
> > On 4/11/17, 7:36 AM, "Development on behalf of Tuukka Turunen" 
> >  wrote:
> > every fix that would have been part of 5.8.1 and more – a lot more. 
>
>The reason for pushing to the 5.8 branch is because it *is* stable.  And 
> since it has "... a lot more", the 5.9 branch is not stable.  

I was actually not referring to features, but the fact that quite a lot of bug 
fixes have been pushed to 5.9 and these are not present in 5.8 branch.

> Whether The Qt Company will generate any packaged versions on the 5.8 branch 
> after 
> the 5.8.0 release is really not the point, is it?
>For those that are building from source and who have requirements for 
> stability vs. new features, doesn't there need to be a stable HEAD to push 
> to?  If the 5.8 branch is closed, those developers will be forced to move
>  to 5.9 beta, or be required to find, cherry-pick and validate commits onto 
> 5.8 themselves, right?  Leaving the branch open, with CI runs on changes, 
> seems like the only way to keep a known stable HEAD available until
>  the known stable HEAD is on the 5.9 branch.

The problem with pushing some fixes to 5.8 is that we need to do merges up 
(which need effort from people, machine cycles and calendar time). This is the 
penalty we take when there are patch releases coming from the stable branch. It 
is a major impact to the next release. 

Now that there are no patch releases planned, the benefit from pushing to 5.8 
then merging to 5.9 does not exist. That is the key point – we need to create a 
stable base for users, catch up with lost time due to 5.8 delay, and to be able 
to implement a major change in CI so that we can make patch releases easier in 
the future.

So this is not about changing the approach in general – just a temporary action 
to be able to reach the abovementioned goals. 

Yours,

Tuukka


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

Re: [Development] Qt 5.10 schedule proposal

[Tuukka Turunen]

On 13/04/2017, 15.30, "Development on behalf of Konstantin Tokarev" 
 wrote:



13.04.2017, 15:11, "Bogdan Vatra" :
> It's just me or did you forgot to add 5.8.1?

I think I hear how Mr. Turunen is pulling his hair out reading this :)

Yes, quite right. 

Yours,
Tuukka

>
> Cheers,
> BogDan.
>
> On joi, 13 aprilie 2017 11:48:06 EEST Jani Heikkinen wrote:
>>  After short internal discussion here is my proposal for those patch 
level
>>  releases:
>>
>>  - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 
5.6.3
>>  release target August 2017 - Branch '5.9.1' from '5.9' at the end of
>>  July/beginning of August, 5.9.1 release target September 2017 - Branch
>>  '5.9.2' from '5.9' Nov 2017
>>  - Branch '5.6.4' from '5.6' Jan 2018
>>
>>  br,
>>  Jani
>>
>>  > -Original Message-
>>  > From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
>>  > project.org] On Behalf Of Thiago Macieira
>>  > Sent: maanantaina 10. huhtikuuta 2017 18.46
>>  > To: development@qt-project.org; releas...@qt-project.org
>>  > Subject: Re: [Development] Qt 5.10 schedule proposal
>>  >
>>  > Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen
>>  >
>>  > escreveu:
>>  > > Hi,
>>  > >
>>  > > Qt 5.9 is proceeding quite well and it is time to start planning Qt
>>  > > 5.10 schedule. We want to to release 5.10 before Christmas so we 
need
>>  > > to have Qt
>>  > > 5.10 FF at the beginning of August. I propose following initial
>>  > > schedule for Qt 5.10:
>>  > >
>>  > > - Qt 5.10 Feature Freeze: 8.8.2017
>>  > > - Qt 5.10 Alpha Release: 31.8.2017
>>  > > - First Qt 5.10 Beta Release 5.10.2017
>>  > > - Qt 5.10 RC 16.11.2017
>>  > > - Qt 5.10 final release 30.11.2017
>>  >
>>  > Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, 
so we
>>  > have an idea of how much work it will be?
>>  >
>>  > --
>>  > Thiago Macieira - thiago.macieira (AT) intel.com
>>  >
>>  > Software Architect - Intel Open Source Technology Center
>>  >
>>  > ___
>>  > Development mailing list
>>  > Development@qt-project.org
>>  > http://lists.qt-project.org/mailman/listinfo/development
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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


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

Re: [Development] Qt 5.10 schedule proposal

[Tuukka Turunen]

Hi,

As discussed earlier this week 5.8 branch will be closed now, in essence as 
soon as Oswald gets to it.

Yours,

Tuukka

From: bogdan.va...@kdab.com  on behalf of Bogdan Vatra 

Sent: Thursday, April 13, 2017 3:36:32 PM
To: Tuukka Turunen
Cc: Konstantin Tokarev; development@qt-project.org
Subject: Re: [Development] Qt 5.10 schedule proposal

On joi, 13 aprilie 2017 12:34:27 EEST Tuukka Turunen wrote:
> On 13/04/2017, 15.30, "Development on behalf of Konstantin Tokarev"
>  annu...@yandex.ru> wrote:

>
>
> 13.04.2017, 15:11, "Bogdan Vatra" :
>
> > It's just me or did you forgot to add 5.8.1?
>
>
> I think I hear how Mr. Turunen is pulling his hair out reading this :)
>
> Yes, quite right.
>

My colleagues told me all the story, what I don't understand is why 5.8 branch
is not closed. I just pushed quite a few patches in that branch ...

BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Stepping down as the QNX maintainer / proposing James McDonnell

[Tuukka Turunen]

Thanks Rafael for your work on this. I see James very well fit for this role.

Yours,

Tuukka

On 19/04/2017, 16.05, "Development on behalf of Rafael Roquetto" 
 wrote:

Hello,

I would like to announce that I am stepping down as the QNX maintainer. I
would like to propose James McDonnell from QNX for the role. I believe he is
the right person to carry on the maintenance of QNX on Qt, because:

* he works for QNX, and therefore has a better contextual overview of 
what
  needs to be done and considered.
* he has been comitting to Qt on QNX for quite a while, being even more
  active than myself. James is an approver and has been working on 
several
  fronts, including QtMultimedia, general bugfixing and brigging 
excellent
  QNX support into QtCreator.

Long live Qt on QNX!

Rafael

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts


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

Re: [Development] Testing help needed

[Tuukka Turunen]

Hi,

There were quite many people who expressed interest a few months ago to help in 
making the releases, so hopefully we get a lot of suggestions to better engage 
with the whole community for testing the releases.

Quite many are testing new Qt versions with their applications and reporting 
issues via bugreports. This is really valuable and we hope that with the new 
process of multiple betas available via the online installer this testing 
becomes even easier.

In addition we would like to have people to test new releases for wider 
functionality than just what their app needs. Optimally all, but that is of 
course not possible in practice.

We have automatic testing in place with quite good coverage, but in order to 
catch all the needed issues manual testing is still beneficial. This is what 
Jani is asking volunteers to help with.

The sooner we find issues to fix, the better. So time for testing is now.

Yours,

Tuukka

From: Development  on 
behalf of Jani Heikkinen 
Sent: Tuesday, April 25, 2017 11:39:48 AM
To: development@qt-project.org; releas...@qt-project.org
Cc: inter...@qt-project.org
Subject: [Development] Testing help needed

Hi all,

There is now wiki page for reporting testing effort and results in 
https://wiki.qt.io/Qt59_release_testing . I also asked you all to take a tour 
for Qt 5.9 beta2 & report the effort via it. As you can see there isn't really 
any reports from community yet. It would be really beneficial for Qt to get 
packages tested early enough & find all release blockers well before official 
release. That would help us to keep the schedules and improve the release 
quality. So do you have some ideas how to get you all better involved to this? 
Is wiki page & table easy enough for this or should we use some other format? 
Getting you involved to this more will help us to do more patch level releases 
in the future as well (which has been the hot topic during this spring)...

br,
Jani




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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Tuukka Turunen]

Hi,

Related to the Apple platforms, could we consider the following for Qt 5.10:
- Drop the older iPhone support by removing ARMv7 from iOS 
(http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf)
- Consider also dropping ARMv7s support, which would allow dropping i386 
simulator support
- Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus 
supporting three latest ones means dropping one)

Yours,

Tuukka

On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" 
 wrote:


> On Apr 27, 2017, at 2:29 AM, Heikki Halmet  wrote:
> 
> Hi,
>  
> Below we have proposal for changes in supported platforms and 
configurations from Qt 5.9 to 5.10.
> Please comment if the proposal is insufficient or the changes are 
unacceptable somehow.
>  
> Please refer to Qt 5.9 Supported platforms -> 
http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html
>  
> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10:
> RHEL 7.2 -> RHEL 7.3 (Any benefits?)
> OpenSUSE 42.1 -> OpenSUSE 42.2
> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI)
> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available)

Apple does not ever release updates to older release series, so since 8.3 
already exists, this is guaranteed to remain 8.2.1.

> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available)

8.3.2, please.

> Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 
> Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3
> INTEGRITY GHS 2016.5.4 -> 2017.1.x 
> Support for Android 8 (if available on time)
> iOS 11 support (if available on time. Current rumors -> september)
>  
> MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 
5.10 is at the beginning of August.
> This means that we can only use Preview release of 10.13 for testing 
before final official release is out.
> That can cause situation that we don’t have enough time to get 10.13 in 
before 5.10 release so we can’t give guarantees that 10.13 will be supported in 
5.10.

How do you know it won't be called macOS 11? ;)

The purpose of the preview release *IS* to use it for testing so that you 
can say your product supports the final version (according to Apple). We should 
provision a VM for the first developer preview and update it throughout the 
beta cycle until the final release. So this should not be a problem for us with 
FF in August unless Qt 5.10 releases before macOS Next does.

Just for the record: make sure not to drop CI for macOS 10.10 - that 
version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 
10.10 support.

>  
> NOTE! We will commit to wanted platform and software changes as long as 
those are available straight after 5.9 release is out in the end of the May.
> With all others we'll do the best we can but we can't commit that those 
will be supported in 5.10.
>  
>  
>  
> Best regards
> Heikki Halmet
>  
> The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland
> Email: heikki.hal...@qt.io
> Phone: +358408672112
> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject 
Facebook: www.facebook.com/qt
>  
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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


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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Tuukka Turunen]

Correcting myself: Drop ARMv7 and ARMv7s support for iOS, meaning we only 
support 64bit iOS devices from Qt 5.10 onwards.

Yours,

Tuukka

From: Development  on 
behalf of Tuukka Turunen 
Sent: Thursday, April 27, 2017 4:07:48 PM
To: Jake Petroules; Heikki Halmet; development@qt-project.org
Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations 
changes


Hi,

Related to the Apple platforms, could we consider the following for Qt 5.10:
- Drop the older iPhone support by removing ARMv7 from iOS 
(http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf)
- Consider also dropping ARMv7s support, which would allow dropping i386 
simulator support
- Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus 
supporting three latest ones means dropping one)

Yours,

Tuukka

On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" 
 wrote:


> On Apr 27, 2017, at 2:29 AM, Heikki Halmet  wrote:
>
> Hi,
>
> Below we have proposal for changes in supported platforms and 
configurations from Qt 5.9 to 5.10.
> Please comment if the proposal is insufficient or the changes are 
unacceptable somehow.
>
> Please refer to Qt 5.9 Supported platforms -> 
http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html
>
> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10:
> RHEL 7.2 -> RHEL 7.3 (Any benefits?)
> OpenSUSE 42.1 -> OpenSUSE 42.2
> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI)
> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available)

Apple does not ever release updates to older release series, so since 8.3 
already exists, this is guaranteed to remain 8.2.1.

> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available)

8.3.2, please.

> Windows 7 MinGW 5.3.0 -> MinGW 6.3.0
> Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3
> INTEGRITY GHS 2016.5.4 -> 2017.1.x
> Support for Android 8 (if available on time)
> iOS 11 support (if available on time. Current rumors -> september)
>
> MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 
5.10 is at the beginning of August.
> This means that we can only use Preview release of 10.13 for testing 
before final official release is out.
> That can cause situation that we don’t have enough time to get 10.13 in 
before 5.10 release so we can’t give guarantees that 10.13 will be supported in 
5.10.

How do you know it won't be called macOS 11? ;)

The purpose of the preview release *IS* to use it for testing so that you 
can say your product supports the final version (according to Apple). We should 
provision a VM for the first developer preview and update it throughout the 
beta cycle until the final release. So this should not be a problem for us with 
FF in August unless Qt 5.10 releases before macOS Next does.

Just for the record: make sure not to drop CI for macOS 10.10 - that 
version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 
10.10 support.

>
> NOTE! We will commit to wanted platform and software changes as long as 
those are available straight after 5.9 release is out in the end of the May.
> With all others we'll do the best we can but we can't commit that those 
will be supported in 5.10.
>
>
>
> Best regards
> Heikki Halmet
>
> The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland
> Email: heikki.hal...@qt.io
> Phone: +358408672112
> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject 
Facebook: www.facebook.com/qt<http://www.facebook.com/qt>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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


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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Tuukka Turunen]

Hi,

While I do agree that having a platform in CI and supporting it for those who 
have purchased support are not 1:1, in case of dropping the 32-bit iOS from CI 
for Qt 5.10 it also means that this configuration should no longer be used and 
not be supported. I do not see much problems with that as we continue to 
support 32 bit iOS for earlier platforms (until Apple drops it) and the 32 bit 
iOS devices are already quite old.

Yours,

Tuukka


On 28/04/2017, 19.58, "Jake Petroules"  wrote:


> On Apr 27, 2017, at 11:28 PM, Lars Knoll  wrote:
> 
> 
>> On 27 Apr 2017, at 16:59, Jake Petroules  wrote:
>> 
>>> 
    >>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen  
wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> Related to the Apple platforms, could we consider the following for Qt 
5.10:
>>> - Drop the older iPhone support by removing ARMv7 from iOS 
(http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf)
>>> - Consider also dropping ARMv7s support, which would allow dropping 
i386 simulator support
>> 
>> I really don't like how we use the term "support" in these emails 
because it's rather misleading. We use it to mean "tested in CI", whereas I 
(and most of the world, as far as I can tell) read it as "the code exists and 
is functional". "Removing support" to me means actively removing the code which 
makes something functional.
> 
> Agree, there is a difference between the two. 
> 
> What I think we should however do for 5.10 is remove 32bit support for 
iOS from CI and our binary packages. And that means that things will be 
untested on 32bit iOS, and thus is likely to break at some point.

I think 32-bit support on iOS is kind of unlikely to break accidentally, 
but I agree we should remove it from our binary packages. The iPhone 5 is dead.

>> 
>> As an Open Source project, we need to keep in mind that dropping first 
party "support" for something means little to nothing unless we actually delete 
the associated code as well and refuse patches to re-add it, because people can 
always build their own copy of Qt, and commercial support will obviously still 
answer queries for most definitions of "unsupported", making the term 
"unsupported" a little meaningless. Perhaps we can start using the term "tier 1 
support" as a synonym for what we actually mean by "support", in order to be 
more clear? I really liked the notion of tiered support that we used to have 
but it seems to have gone missing…
> 
> For the commercial version, it’s to a large extent up to TQtC to define 
the support offering. The open source project anyway does not offer any 
official support for the Qt versions released. All you can do is ask on the 
mailing lists or file a bug report and hope for the best. Or of course sit 
down, fix it yourself and submit a patch :)

My point was that if a commercial customer goes to support with a bug in a 
32-bit build of Qt for iOS, support won't say "we do not support that, go 
away". They will fix the problem, regardless of the fact that it isn't part of 
a reference configuration.

If a customer sets the minimum deployment target of Qt for iOS to 5.0 and 
then goes to support saying Qt doesn't work, support WILL tell them "we do not 
support that (because we deliberately broke it), we can't help you and you'll 
have to talk to Services and pay money if you want it working that badly".

That's the real-world outcome, which is why I don't like using the term 
"supported" as a synonym for "is a reference configuration in CI".

A reference configuration in CI always constitutes something that is 
supported. However, something that's supported is not necessarily a reference 
configuration in CI. We should make this clear to our users by not using the 
term "supported" in a misleading way.

> 
>> 
>> Something like the following seems nice:
>> Tier 1 - the most rigorously tested configurations, tested in CI
>> Tier 2 - we actively try to make it work but it's a lower priority; will 
make and accept patches and provide support but isn't tested in CI
>> Unsupported - we remove code that makes the functionality work; will 
refuse any related patches, commercial support refers queries to a separate 
(paid) business engagement
> 
> I’m ok to describe things in tiers, as that’s what we have in practice. 
We don’t test e.g. FreeBSD in CI, but we will accept patches if something’s 
broken on that platform and someone cares en

Re: [Development] QtWebKit is coming back (part 2)

[Tuukka Turunen]

Hi,

There has also been some interest also for getting Qt WebEngine to be released 
much faster cycle than Qt – exactly due to the security update need. Even if we 
succeed in making substantially more frequent Qt patch releases than before, it 
may still be better if user would have the option to update some parts (like 
QWE) more frequently or out of sync. 

I think what we should consider, is to perhaps carve out Qt WebEngine from Qt 
as well. Not immediately, but for Qt 6 we should anyway consider our current 
setup of essential and add-on modules. For the html5 engine there is the matter 
of binary size in addition to release frequency. This is not to say that we 
would stop developing html5 engine – just that it might be beneficial to do in 
in different way than currently. 

For new updated Qt Webkit, perhaps we could have it as a separate item that 
works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
After it has existed for a while as a separate item, it is also easier to know 
what would be the best way to get it into a Qt release – or is that even 
necessary. 

Yours,

Tuukka

On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
 wrote:
   

04.05.2017, 19:35, "Oswald Buddenhagen" :
> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>>  03.05.2017, 17:27, "Sergio Martins" :
>>  > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  >>  Remaining question is versioning. While it's fine to dub current
>>  >>  release "5.9" (but not 5.0, because we will have another WebKit 
update
>>  >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>  >>
>>  >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 
5.N,
>>  >>  or is updated
>>  >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  >>  5.2 as of now), and can be used e.g. as security update in Linux
>>  >>  distro that does not normally update Qt version during its life 
cycle.
>>  >>
>>  >>  Any comments?
>>  >
>>  > If Qt and QtWebKit will have different release schedules then that
>>  > numbering would indeed confuse people.
>>
>>  What about choice of new versioning scheme?
>>
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x 
and makes it
>>  clear that versioning is different now. Bug fixes will increment patch 
version (6.0.x),
>>  WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
major
>>  verison (7.0 etc.)
>>
>>  Qt5 supermodule will be tracking latest available stable branch. When 
release branch
>>  is created (e.g. 5.10.0), corresponding patch release branch is created 
in qtwebkit
>>  repo (e.g., 6.1.1) and is frozen following the same schedule as Qt 
release branches.
>>
>>  However, I'm not sure about two things:
>>  1) Is it possible to have custom branch names in qtwebkit repository, 
or there need to
>>  be virtual 5.10 etc. branches to match other modules?
>>  2) What about bug tracking in JIRA? I would like to keep existing 
issues as is, but assing
>>  new release numbers to items fixed in new releases
>
> i'll say outright that you can't be part of the qt supermodule and yet
> have independent releases. while that was the plan once upon a time, the
> whole release infrastructure simply doesn't deliver, and even just
> diverging branch names are a pita (proved by enginio). as a product, qt
> is as monolithic as ever.

Understood: no custom branch/tag names in official repo.

>
> your release cycle concerns seem to be centered around the webkit
> backend, and you can deal with that by lowering the compatibility
> guarantees of patch releases at this level, i.e. take the freedom to
> upgrade webkit in a patch release. as long as you keep qt's api/abi
> compat promises, you're fine. that means that you will not be able to
> expose new webkit features until the next minor release if they require
> new api.

That's probably fine with me, except 2 moments that seem to require "out of 
band" releases:

1. Something should be done with current release. As I said, it's not an 
option to postpone
it to 5.10, however it also cannot be released as 5.9.1 because there are 
API additions
which I don't want to revert (in particular because these APIs were already 
shipped by
Linux distros that chose to provide TP4 and TP5). Also there is a change in 
QDataStream
format of QWebHistory.

2. Security updates. WebKitGTK team provides several patch releases for 
each stable branch,
which contain only fixes for bugs and security issues, and towards the end 
of release life cycle
they became primarily security updates. I think we should be able to 

Re: [Development] CI problems

[Tuukka Turunen]

Awesome. Thanks, Tony (and others who worked to get this resolved quickly)!

Yours,

Tuukka

From: Development  on 
behalf of Tony Sarajärvi 
Date: Thursday, 18 May 2017 at 22.46
To: "development@qt-project.org" 
Subject: Re: [Development] CI problems

(Apparently it was just my own inbox not being updated 😉)

It now looks like we have a running CI again!
I started Coin and everything seems to be running as normal. I’ll keep watching 
it for a while longer and then resume work in the morning. Thanks for your 
patience.

-Tony

From: Development 
[mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf Of 
Tony Sarajärvi
Sent: torstaina 18. toukokuuta 2017 20.17
To: development@qt-project.org
Subject: [Development] CI problems

Hi

Seems my earlier 2 mails haven’t reached you. I hope this one does.

We’ve suffered hardware malfunction today. Our CI environment began behaving 
oddly aprox 20 hours ago and early this morning we noticed that not everything 
was OK. To prevent data loss and further problems, we shut down the CI.

It took a lot of time to narrow the problem down, and we still aren’t 100% sure 
where the problem is, but we have a good suspect currently. We have 24/7 teams 
on this issue trying to get everything fixed.

Bear with us. We’ll be back as soon as possible.

-Tony
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI problems

[Tuukka Turunen]

Thanks for the update and getting things back on track.

Yours,

Tuukka

From: Development  on 
behalf of Tony Sarajärvi 
Sent: Friday, May 19, 2017 9:36:45 PM
To: development@qt-project.org
Subject: Re: [Development] CI problems

Better new this time. Aprox 3 hours ago I got green light to start the CI 
again. An hour into the run I stumbled upon a non-infra related small issue, 
which got fixed by a simple quick restart. After that builds have been running 
OK and as I saw first green results and commits being merged I felt confident 
to send this e-mail. So, all seem to be working again. (Fingers crossed)

We have extra pair of eyes on the system this weekend, and I’ll keep you 
informed if it goes to a halt again.

Thanks for your patience
-Tony

From: Development 
[mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf Of 
Tony Sarajärvi
Sent: perjantaina 19. toukokuuta 2017 12.17
To: development@qt-project.org
Subject: Re: [Development] CI problems

Hi again ☹

Something hit the fan again, and all CI systems came to a halt. IT has been 
contacted who will contact Dell immediately. I’ll keep you updated as I have 
receive info.

-Tony

From: Tuukka Turunen
Sent: perjantaina 19. toukokuuta 2017 0.54
To: Tony Sarajärvi mailto:tony.saraja...@qt.io>>; 
development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] CI problems


Awesome. Thanks, Tony (and others who worked to get this resolved quickly)!

Yours,

Tuukka

From: Development 
mailto:development-bounces+tuukka.turunen=qt...@qt-project.org>>
 on behalf of Tony Sarajärvi mailto:tony.saraja...@qt.io>>
Date: Thursday, 18 May 2017 at 22.46
To: "development@qt-project.org<mailto:development@qt-project.org>" 
mailto:development@qt-project.org>>
Subject: Re: [Development] CI problems

(Apparently it was just my own inbox not being updated 😉)

It now looks like we have a running CI again!
I started Coin and everything seems to be running as normal. I’ll keep watching 
it for a while longer and then resume work in the morning. Thanks for your 
patience.

-Tony

From: Development 
[mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf Of 
Tony Sarajärvi
Sent: torstaina 18. toukokuuta 2017 20.17
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: [Development] CI problems

Hi

Seems my earlier 2 mails haven’t reached you. I hope this one does.

We’ve suffered hardware malfunction today. Our CI environment began behaving 
oddly aprox 20 hours ago and early this morning we noticed that not everything 
was OK. To prevent data loss and further problems, we shut down the CI.

It took a lot of time to narrow the problem down, and we still aren’t 100% sure 
where the problem is, but we have a good suspect currently. We have 24/7 teams 
on this issue trying to get everything fixed.

Bear with us. We’ll be back as soon as possible.

-Tony
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.10 Feature Freeze is coming

[Tuukka Turunen]

Hi,

If you are still developing in a feature branch, please merge to dev as soon as 
possible. Unless you are already aiming to Qt 5.11, that is.

We should avoid "last minute" merges as these are likely to cause problems.

Yours,

Tuukka

From: Development  on 
behalf of Jani Heikkinen 
Sent: Friday, June 2, 2017 9:29:17 AM
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Development] Qt 5.10 Feature Freeze is coming

Hi all!

Just a kindly reminder: Qt 5.10 Feature Freeze date is 8.8.2017 so there isn't 
really more than 2 months time left to get new features in (see 
https://wiki.qt.io/Qt_5.10_Release ).

We kept final schedule with Qt 5.9.0 and we need to continue that with Qt 5.10. 
So if you already now see that some feature won't be ready early enough please 
postpone it to 5.11 instead.

Please make sure all new features are visible in new feature page 
(https://wiki.qt.io/New_Features_in_Qt_5.10)  as soon as possible. Please also 
make sure new features are fulfilling ff criteria 
(https://wiki.qt.io/Qt_5_Feature_Freeze). And make sure all new modules are in 
qt5.git early enough, at this time latest at the end of June (also possible new 
Technology Preview ones): FF is immediately after summer holiday period and we 
need to create configurations etc for those as well before FF. That's why we 
need to get new modules in qt5.git as early as possible.

At the moment I don't know any new module for Qt 5.10. If there will be some 
please inform me immediately with details(we can start preparations for those 
already now):
   - Module name & repository
   - Officially supported/TP
   - Description for installer
   - Supported platforms
   - etc

And also inform me if some already existing module change it's state (e.g 
TP->officially supported, deprecated etc)

br,
Jani Heikkinen
Release Manager



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

Re: [Development] Qt 5.10 pre-built binaries

[Tuukka Turunen]

Hi,

Dropping ARMv7 and i386 iOS binaries should help in this.

Yours,

Tuukka

From: Development  on 
behalf of Marco Piccolino 
Date: Thursday, 8 June 2017 at 8.37
To: "development@qt-project.org" 
Subject: Re: [Development] Qt 5.10 pre-built binaries

Hello,
Would you also consider creating a smaller macOS offline installer? Current 
version with Android and iOS is at 3.5 Gb and has been reported to cause 
persistent timeouts when downloaded on CI like Travis.
Is providing android and iOS as add-on installs an option?

Marco Piccolino

Il 07 giu 2017 9:30 AM, 
mailto:development-requ...@qt-project.org>> 
ha scritto:
Send Development mailing list submissions to
development@qt-project.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.qt-project.org/mailman/listinfo/development
or, via email, send a message with subject or body 'help' to

development-requ...@qt-project.org

You can reach the person managing the list at

development-ow...@qt-project.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Development digest..."

Today's Topics:

   1. Re: Future of Qt on Web? (Konstantin Tokarev)
   2. Re: Future of Qt on Web? (Lorn Potter)
   3. Re: Future of Qt on Web? (Jason H)
   4. Re: Nominating Vikas Pachdha for Approver status (Alex Blasche)
   5. Qt 5.10 pre-built bunaries (Jani Heikkinen)
   6. Re: Qt 5.10 pre-built bunaries (Lars Knoll)


-- Messaggio inoltrato --
From: Konstantin Tokarev mailto:annu...@yandex.ru>>
To: Jason H mailto:jh...@gmx.com>>, Lorn Potter 
mailto:lorn.pot...@gmail.com>>
Cc: "development@qt-project.org" 
mailto:development@qt-project.org>>
Bcc:
Date: Mon, 05 Jun 2017 17:22:26 +0300
Subject: Re: [Development] Future of Qt on Web?


05.06.2017, 17:20, "Jason H" mailto:jh...@gmx.com>>:
>>  Sent: Monday, June 05, 2017 at 12:34 AM
>>  From: "Lorn Potter" mailto:lorn.pot...@gmail.com>>
>>  To: development@qt-project.org
>>  Subject: Re: [Development] Future of Qt on Web?
>>
>>  On 06/05/2017 07:00 AM, Jason H wrote:
>>  > While Qt is not a web framework, over time there have been efforts to use 
>> it on the web (outlined below).
>>  >
>>  > Given that Chrome is dropping NaCL 
>> (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html)
>>  and the WebGL streaming is also not ideal (but better?), I am wondering 
>> about the future of Qt on Web? Will there be a WebAssembly version of Qt?
>>
>>  We have been working on Qt5 for webassembly.
>>  I was just writing a short blog about this:
>>
>>  http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html
>
> That is great news! You mention the wasm is smaller? How much smaller?

This article says it's smaller than asm.js, not NaCl

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Regards,
Konstantin



-- Messaggio inoltrato --
From: Lorn Potter mailto:lorn.pot...@gmail.com>>
To: Jason H mailto:jh...@gmx.com>>
Cc: development@qt-project.org
Bcc:
Date: Tue, 6 Jun 2017 05:26:53 +1000
Subject: Re: [Development] Future of Qt on Web?


On 06/06/2017 12:20 AM, Jason H wrote:
>
>
>> Sent: Monday, June 05, 2017 at 12:34 AM
>> From: "Lorn Potter" mailto:lorn.pot...@gmail.com>>
>> To: development@qt-project.org
>> Subject: Re: [Development] Future of Qt on Web?
>>
>>
>>
>> On 06/05/2017 07:00 AM, Jason H wrote:
>>> While Qt is not a web framework, over time there have been efforts to use 
>>> it on the web (outlined below).
>>>
>>> Given that Chrome is dropping NaCL 
>>> (http://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html)
>>>  and the WebGL streaming is also not ideal (but better?), I am wondering 
>>> about the future of Qt on Web? Will there be a WebAssembly version of Qt?
>>
>> We have been working on Qt5 for webassembly.
>> I was just writing a short blog about this:
>>
>> http://qtandeverything.blogspot.com.au/2017/06/qt-for-web-assembly.html
>
> That is great news! You mention the wasm is smaller? How much smaller?

For one small example app (standarddialog) the difference between asmjs
and wasm is:

wasm: 520 k js file and 14 MB wasm file.
asmjs: 69 MB js file.




-- Messaggio inoltrato --
From: Jason H mailto:jh...@gmx.com>>
To: Lorn Potter mailto:lorn.pot...@gmail.com>>
Cc: development@qt-project.org
Bcc:
Date: Mon, 5 Jun 2017 21:51:53 +0200
Subject: Re: [Development] Future of Qt on Web?


> Sent: Monday, June 05, 2017 at 3:26 PM
> From: "Lorn Potter"