[Development] Qt 5.11.0 released

[Jani Heikkinen]

Hi everyone!

I am happy to announce that Qt 5.11.0 is released today, see 
http://blog.qt.io/blog/2018/05/22/qt-5-11-released/
At this time we were ready slightly before originally estimated; big thanks to 
everyone involved!

br,
Jani Heikkinen
Release Manager
The Qt Company
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] HEADS UP: Branching from '5.9' to '5.9.6' completed

[Jani Heikkinen]

Hi,

Branching from '5.9' -> '5.9.6' now done and '5.9' is for Qt 5.9.7.  So all 
changes targeted to Qt 5.9.6 must be done in '5.9.6' from now on.
Target is to create Qt 5.9.6 "rc" soon, test it and if all OK release Qt 5.9.6 
at the beginning of June.  So please make sure all release blockers are visible 
in 5.9.6 blocker list (https://bugreports.qt.io/issues/?filter=19339)

br,
Jani

> -Original Message-
> From: Development  project.org> On Behalf Of Jani Heikkinen
> Sent: keskiviikko 9. toukokuuta 2018 14.01
> To: development@qt-project.org
> Cc: releas...@qt-project.org
> Subject: [Development] HEADS UP: Branching from '5.9' to '5.9.6' started
> 
> Hi,
> 
> We have soft branched '5.9.6' from '5.9' already today. This was done a bit
> earlier than informed but don't worry; final downmerge from '5.9' to '5.9.6'
> will happen Tue 22.5.2018 as planned. So there is now plenty of time to
> finalize ongoing changes in '5.9' and start using '5.9.6' for new changes
> targeted to Qt 5.9.6 release. Plan is to get Qt 5.9.6 out at the beginning of
> June
> 
> 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

[Development] Do we really need Assimp?

[Thiago Macieira]

Given the number of warnings in this codebase, I am really skeptical about the 
quality of the code. Today, compiling with GCC, Clang an ICC, I saw the 
following warnings scroll by, which are real issues:

LWSLoader.cpp:428:14: warning: duplicated ‘if’ condition [-Wduplicated-cond]

new_allocator.h:140:22: warning: destructor called on non-final 
'Assimp::FICDATAValueImpl' that has virtual functions but non-virtual 
destructor [-Wdelete-non-virtual-dtor]

miniz.h(4430): warning #592: variable "level" is used before its value is set

And then there are of course warnings that indicate none of their developers 
are testing new compilers, like

LWOLoader.cpp:1408:13: warning: this statement may fall through [-Wimplicit-
fallthrough=]

Can we get rid of it?

If not, can I ask someone to compile it with CONFIG += warn_off, to hide all 
that ugliness? Those warnings make finding our warnings more difficult and it 
affects our reputation because people see warnings and think they're Qt's 
fault.

Qt3D maintainers, please take action to make sure those warnings disappear 
from our builds.
-- 
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

Re: [Development] Repository Request: qt/licensing

[Thiago Macieira]

On Friday, 18 May 2018 18:18:02 -03 Thiago Macieira wrote:
> > Just for clarification: The official source packages contain the licheck
> > executables already. My aim is that a git checkout and the source packages
> > we provide contain the very same content.
> 
> I understand, but I'm asking you not to.

Here's something that would be acceptable:

Do create the qt/licensing repo but make it empty, or just a README file or 
whatever is necessary. This repository can live in qt-project.org and be 
mirrored under github.com/qtproject.

In your internal infra, use a different repository branched off from the 
public one, containing the licence checker binary and anything else you may 
need. This repository should never be shared.

It's no different than my own qtbase, except that I do share it:
https://gitlab.com/thiagomacieira/qtbase

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

[Phil Bouchard]

Way to go Qt!
http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/

I suggested this in a previous thread but apparently you already had grips
on it.

Well good job folks!


Sincerely,
-Phil
www.fornux.com

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

Re: [Development] Stepping down as maintainer

[Oswald Buddenhagen]

On Mon, Apr 09, 2018 at 06:37:23AM +, Alexander Blasche wrote:
> All required Jira and https://wiki.qt.io/Maintainers updates have been done.
> 
well, actually, the top-level "gui" item is still naming gunnar.
and in jira we have no "gui: other" component at all ...

> --
> Alex
> 
> 
> From: Development 
>  on behalf of 
> Gunnar Sletta 
> Sent: Monday, 19 March 2018 1:39:50 PM
> To: development
> Subject: [Development] Stepping down as maintainer
> 
> Hi,
> 
> After quite some time of not being active in Qt, I am now formally stepping 
> down as maintainer. It has been a great ride, but I simply don't have time to 
> follow up Gui and Scene Graph and it makes sense that the people who are 
> active in these areas also become the go-to guys.
> 
> I've already spoken with Eskil and Lars, and propose the following list of 
> people to formally take over my areas:
> 
> Tor Arne Vestby - QPA and window system integration
> Laszlo Agocs - OpenGL/Vulkan
> Eirik Aavitsland - Image Formats and QPainter
> Andy Nichols - Scene Graph
> 
> (Other specific maintainers in QtGui stay unchanged)
> 
> Thanks,
> Gunnar
> ___
> 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] Naming convention for (scoped) enums

[Lars Knoll]

> On 17 May 2018, at 11:35, Christian Kandeler  wrote:
> 
> On Thu, 17 May 2018 08:14:15 +
> Alex Blasche  wrote:
> 
>> The naming conventions for enums state that each enum value name must repeat 
>> a part of the enum Type name (for details see 
>> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)
>> 
>> In case of scoped enums this becomes a superfluous rule as the type has to 
>> be mentioned anyway. Does anybody object to modifying the above definition 
>> by adding an exception for scoped enums where you do not have to repeat a 
>> part of the enum type name?
> 
> I would not have even assumed that the rule applies to scoped enums, but it 
> can't hurt to write it down explicitly. Perhaps the section should be 
> rewritten so that the unscoped enums are the special case rather than the 
> other way around.

Agree. The default for new enums should be scoped enums.

Cheers,
Lars

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

Re: [Development] Naming convention for (scoped) enums

[Alex Blasche]

I updated the enum section:

https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values

--
Alex


From: Development  
on behalf of Lars Knoll 
Sent: Tuesday, 22 May 2018 9:30:18 AM
To: Christian Kandeler
Cc: Qt development mailing list
Subject: Re: [Development] Naming convention for (scoped) enums



> On 17 May 2018, at 11:35, Christian Kandeler  wrote:
>
> On Thu, 17 May 2018 08:14:15 +
> Alex Blasche  wrote:
>
>> The naming conventions for enums state that each enum value name must repeat 
>> a part of the enum Type name (for details see 
>> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)
>>
>> In case of scoped enums this becomes a superfluous rule as the type has to 
>> be mentioned anyway. Does anybody object to modifying the above definition 
>> by adding an exception for scoped enums where you do not have to repeat a 
>> part of the enum type name?
>
> I would not have even assumed that the rule applies to scoped enums, but it 
> can't hurt to write it down explicitly. Perhaps the section should be 
> rewritten so that the unscoped enums are the special case rather than the 
> other way around.

Agree. The default for new enums should be scoped enums.

Cheers,
Lars

___
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] Performing infra upgrade in the CI

[Tony Sarajärvi]

Hi

I'm performing a small infra upgrade. I'll be upgrading MAAS to the latest 
version. This shouldn't cause any CI downtime. If something goes badly wrong, 
I'll just revert my change and let's get back to business as usual.

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