[Development] Proposing to add (CPU) architecture maintainers

[Volker Hilsheimer]

> On 3 Aug 2022, at 13:56, Marc Mutz <marc.mutz at qt.io> wrote:
> 
> Hi,
> 
> I'm hitting a wall on architecture-specific patches that aren't x86 (or, 
> to a lesser extent, ARM). 
[…]
> So, I'd like to propose to create a set of CPU architecture maintainers 
> a la the platform maintainers we already have. As per 
> qprocessordetection.h, we purport to support the following architectures:


The list of supported platforms as per https://doc.qt.io/qt-6/supported-platforms.html already doesn’t list any architectures other than x86 and ARM variants. That we happen to have code for other architectures doesn’t imply “support”. We have some ancient #ifdef’ery for HPUX and AIX as well in some places.


> So, we'd need maintainers for the following platforms, or declare the 
> platform unsupported:

The documentation also includes the note that

"Configurations not listed below are not officially supported by the Qt Project. However, Qt may still run on unsupported platforms and configurations. The Qt Company, Qt partners, open source developers, and community users are able to provide assistance in this situation.”

which I think is a pragmatic approach.

> I would expect maintainers to be comfortable approving[1] assembly code 
> for their platform, work (or orchestrate work) towards feature-parity 
> with Qt's x86 support, and ideally getting the architecture into our CI 
> or else making sure locally that the architecture builds and tests pass.


As per the discussion so far, it seems unlikely that having a named maintainer is possible, with the exception of Thiago for x86. And given that practically (?) all assembly seems to live in QtCore, that is anyway implied.

If someone needs to make changes to specific assembly and can’t find a reviewer, then the choices are as always: any approver trusts that the patch author has tested the change locally and is the best qualified person to say whether the change is ok or not - at the risk that we break things on a platform that is not covered by CI (and thus not officially supported anyway). If we are lucky, people and projects testing Qt on such platforms will catch any breakages in time.

Or we decide that the change isn’t worth the risk (or the time), and live with unoptimized (or possible already wrong) code for a certain architecture.

> On 11 Aug 2022, at 10:56, Alex Blasche <alexander.blasche at qt.io> wrote:
> 
>> -----Original Message-----
>> From: Development <development-bounces at qt-project.org> On Behalf Of
>> Thiago Macieira
>> Like I said in my email, we don't have the resources or knowledge to fix
>> architectural-specific issues in those platforms, much less apply performance
>> improvements. But we will accept patches in case we break anything.
> 
> Keeping the above in mind I would like to bring the thread back to 
> https://bugreports.qt.io/browse/QTBUG-103010
> 
> Currently POWER, MIPS, RISC-V and SPARC are open. Since this is an optimization task, I would argue that we close the subtasks for each of the mentioned platforms as Won't Do. Any objections?
> 
> And yes, we'll happily accept patches as outlined by Thiago.
> 
> --
> Alex


Agree, for platforms that nobody is able to/has time to write assembly for, we’ll can continue with an unoptimized, but (presumably) working code path. If someone is motivated to put in the work, then we’ll accept patches. That we can’t write optimized assembly for all possible architectures should either way not block anything.

Volker