then put that information on the document index page for each version in
clear text...
then it would get built into the documentation where downstream actually
looks for it, it gets packaged and deployed downstream,
and the actual users wont know where to even begin to look for the
information.
On Thu, Mar 28, 2024 at 12:14:35PM +0100, Friedemann Kleint via Development
wrote:
> Hi,
>
> I'd say performance should be a consideration for autotests since they are
> compiled and run over and over again in the CI. So, string theory should be
> applied to avoid unnecessary conversions and
On Thursday, 28 March 2024 01:06:37 PDT Björn Strömberg wrote:
> example on spectrum on the support on modules: [unmaintained, deprecated,
> life-support, full-maintenance, feature-development]
The .gitmodules file for qt5.git is that.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Il 28/03/24 12:14, Friedemann Kleint via Development ha scritto:
Hi,
I'd say performance should be a consideration for autotests since they
are compiled and run over and over again in the CI. So, string theory
should be applied to avoid unnecessary conversions and allocations. Even
it is
Hi,
I'd say performance should be a consideration for autotests since they
are compiled and run over and over again in the CI. So, string theory
should be applied to avoid unnecessary conversions and allocations. Even
it is considered a minor optimization, it will have an impact on energy
On 28/03/2024 10:36, Axel Spoerl via Development wrote:
Since _L1 usage is massive in corelib, I wonder whether there is a
standard that everyone can apply when writing or reviewing autotests. If
it exists and I have overlooked it, please forgive my negligence and
point me to it.
*
Hi,
is there any documentation, blog post, wiki page, other source or guideline
about usage of string literals in autotests?
More specifically:
The line
QString ("I love QLatin1StringView");
...triggers 'QString' is deprecated: Use fromUtf8, QStringLiteral, or
QLatin1StringView. QString has
Hi,
Maintainers of Qt modules are listed at: https://wiki.qt.io/Maintainers and my
understanding is that the current Qt 3D maintainers would continue. Module
maintainership as such is not tied in a module being part of the release
configuration or not.
I fully agree that having the module
Hello Tuukka,
thanks for your answer.
In my view, as long as the 'rules' for the module(s) is clearly defined, as
in this case say if KDAB takes over the official maintainer role,
while it still lives under the QtC infra roof, and we still get the modules
dropped with the other sub-modules, then
Hi Björn,
In general, we want to provide longevity and still host many items that are
long ago removed from the main product configuration (or never been part of
it). That said, we also need to have a way to sometimes let go of items in the
main product configuration. Platform support is
10 matches
Mail list logo
