Re: [Development] Nominating Mikołaj Boć as approver

[David Skoland via Development]

+1

Aside from technical prowess, I found it easy to collaborate with Mikolaj to 
find good solutions. I’m confident he will use approver rights wisely.

Disclaimer: we work in the same team.

Cheers,
David Skoland

On 21 Dec 2022, at 22:50, Axel Spoerl via Development 
mailto:development@qt-project.org>> wrote:

+1

Von: Development 
mailto:development-boun...@qt-project.org>> 
im Auftrag von Paul Wicking via Development 
mailto:development@qt-project.org>>
Gesendet: Mittwoch, 21. Dezember 2022 16:09
An: Morten Sørvig mailto:morten.sor...@qt.io>>
Cc: development@qt-project.org 
mailto:development@qt-project.org>>
Betreff: Re: [Development] Nominating Mikołaj Boć as approver

+1

On 21 Dec 2022, at 15:42, Morten Sørvig via Development 
mailto:development@qt-project.org>> wrote:

Hello again,

Correct links to gerrit should be:

https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io

(copy/paste error on my part :)

Morten

On 21 Dec 2022, at 15:21, Morten Sørvig via Development 
mailto:development@qt-project.org>> wrote:

Hi,


I’d like to nominate Mikołaj Boć as an approver for the Qt project.

Mikołaj joined the Qt Company earlier this year and hit the ground running. He 
has contributed features and many bug fixes for the Qt for WebAssembly platform 
integration, as well as bug fixes for other parts of Qt.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: 
https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io
Reviews: 
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io

(I’m a colleague of Mikołaj at the Qt Company where we are on the same team)

Regards,
Morten
___
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 for WebAssembly feature freeze exceptions

[David Skoland via Development]

Hi,

+1 to the emscripten upgrade.

The upgrade is version 3.1.14 -> 3.1.27, which includes a number of fixes which 
are strongly desirable in 6.5.

Cheers,
David Skoland

On 13 Dec 2022, at 11:14, Morten Sørvig via Development 
mailto:development@qt-project.org>> wrote:

Hi all,

We have two pending changes for the wasm platform which I'd like to request a 
feature freeze exception for:

* Adding the initial accessibility backend. This feature will initially be 
opt-in, and we are
 aiming to make it as non-disruptive as possible. A couple of details remains 
to be settled
on the review.

* Updating the SDK to the latest Emcscripten version

(It’s a bit unclear which freeze policy (if any) applies to the SDK update. In 
any case it needs to be done.)

Morten
___
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] IMPORTANT: Gerrit host keys have changed

[David Skoland via Development]

Hi,

This information was already published on this list, but it seems to have been 
missed by a handful of key players (possibly because it was only included in 
the Maintenance break email). Risking informing you all twice, I’ll reiterate 
the memo here.

—

IMPORTANT: Server host keys have been updated.
When doing  a git command you might get warning like:
  @@@
  @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
  @@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that a host key has just been changed.
  The fingerprint for the RSA key sent by the remote host is
  SHA256:EPuL0PAbNuXXoye7X93ARF7/XALxA5XNAaE3p6M/L3g.
  Please contact your system administrator.

— Jukka Jokiniva, Gerrit Admin (original email: 
https://lists.qt-project.org/pipermail/development/2022-November/043215.html)

—

IMPORTANT:
Server host keys on port 29419 [corrected to 28418 in a later email] will be 
updated to support modern algorithms. Also the existing RSA key will be updated 
to a longer key size.
After the change the git commands may fail with errors about mismatched or 
changed host keys or host identification.
To fix this remove locally the old known host key (on Linux based remove the 
corresponding line in ~/.ssh/known_hosts -file)
and verify the new one (git will prompt for verification).

Here are the finger prints of the keys that will applied on 7-Nov:

ssh_host_ecdsa_384_key
384 SHA256:yMnqjnsJU0y6kfiyQQu8pYNGPFE7av5QxbeLdjTKNmk (ECDSA)

ssh_host_ecdsa_521_key
521 SHA256:kytLsqmLdG1KXLO/s3OxOajTYqf1+n7+YqqbOUzNbtE (ECDSA)

ssh_host_ecdsa_key
256 SHA256:El3+EYlXAGylCVo/Y/WYzPg7tS4fjejkepO1JVXUkb0 (ECDSA)

ssh_host_ed25519_key
256 SHA256:DwwqNluQyJVkOk+3bFMK6NwWYIGjMnqGP+R0k59e3CY (ED25519)

ssh_host_rsa_key
4096 SHA256:EPuL0PAbNuXXoye7X93ARF7/XALxA5XNAaE3p6M/L3g (RSA)

— Jukka Jokiniva, Gerrit Admin (original email: 
https://lists.qt-project.org/pipermail/development/2022-November/043213.html)

Cheers,
David Skoland

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

Re: [Development] Bugfixing

[David Skoland via Development]

Hi,

This looks like a pretty old bug. Did you manage to reproduce it on a more 
recent Qt version? The currently supported versions are 5.15 (LTS), 6.2 (LTS), 
6.3 and 6.4.

To submit a patch into the Qt project, you’ll have to go through a couple of 
steps described here: https://wiki.qt.io/Qt_Contribution_Guidelines

Cheers,
David Skoland

On 1 Nov 2022, at 10:48, Taras Kachmaryk 
mailto:gigaxenum...@gmail.com>> wrote:

Hi,
I have a solution for QTBUG-46757. 
How do I add a code? Where can I see the review status?

I will be grateful for your help!
___
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] Using '#pragma once' instead of include guards?

[David Skoland via Development]

Hi,

Using #pragma once does make assumptions about filesystems and compilers, which 
in turn makes assumptions about how Qt is installed and included (and we’ve 
seen a handful of…. creative examples of both).

This results in risk to developers who use Qt (many), which must be weighed 
against convenience for developers who develop Qt (few). It seems like a hard 
sell. The only way you’d have a strong case with this is if it has some other 
significant benefit, like compilation speedup.

Cheers,
David Skoland

On 12 Oct 2022, at 13:25, Hasselmann Mathias 
mailto:math...@taschenorakel.de>> wrote:

Sounds like an excellent plan.

Ciao
Mathias

Am 12.10.2022 um 12:35 schrieb Volker Hilsheimer via Development:
On 11 Oct 2022, at 22:11, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development wrote:
Speaking as co-maintainer of CMake, we have effectively required #pragma
once to build CMake itself since August 2017, we officially codified
this as policy in September 2020, and we will soon be writing a
clang-tidy plugin to enforce this in our CI. We have not received any
complaints about it. Just my $0.02.
Thanks for the information. This confirms what we already knew that all systems
and compilers where Qt would be compiled do support it.

However, neither Qt Creator nor CMake are libraries. They are not comparable.

Thanks all for sharing your insights and digging up the previous discussions as 
well.

The summary of all this then seems to be:

- ok to use '#pragma once’ in headers that are not designed to be included by 
Qt users, i.e. in tools, applications, examples and demos, tests
- for everything else, in particular for public and, for consistency’s sake - 
private headers in Qt, we continue to use conventional include guards

Rationale: #pragma once is not well enough defined and not part of the 
standard, and we cannot make any assumptions about how Qt is installed, used as 
part of a larger SDK etc. So best to stay conservative.

If that’s not entirely off, then I’d like to put this into 
https://wiki.qt.io/Coding_Conventions [1], preempting perhaps a new thread on 
this topic in a few years.

Volker

[1]: And since that page seems rather outdated - e.g. we do use dynamic_cast in 
Qt today, and the suggestion to normalize signals and slots should rather 
suggest to make connections via PMF syntax - perhaps it’s time to move this to 
a QUIP where we can discuss and review such changes in gerrit. I won’t have 
time to do that for a while (perhaps ditto for 
https://wiki.qt.io/Qt_Coding_Style), but perhaps someone else wants to give 
this a shot.

___
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