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

[Lars Knoll]

> On 4 May 2017, at 16:51, Sergio Martins  wrote:
> 
> On 2017-05-04 15:18, Thiago Macieira wrote:
>> Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev
>> escreveu:
>>> But we could have Linux clang configuration with clazy plugin.
>> Why? Clazy is not part of our development philosophy. We should only do that
>> after there's a QUIP explaining which options in Clazy we use (which there
>> isn't).
> 
> Probably the QUIP shouldn't be about clazy /per se/, but about which coding 
> practices we want to enforce via static analysis tooling.
> clazy's current warning set could be used as a starting base for the 
> discussion though, because it exists.

This is getting a bit off topic ;-)

Enforcing certain coding standards is probably a good idea. And we might be 
able to enforce more things in CI once the work on the virtualisation layer is 
done and we can scale up the available hardware.

> 
> But more about that *later*! There's interesting things in the pipeline which 
> KDAB would like to show first.
> 
Looking forward to that :)

Cheers,
Lars

___
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 - SUMMARY

[Sergio Martins]

On 2017-05-04 15:18, Thiago Macieira wrote:

Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev
escreveu:

But we could have Linux clang configuration with clazy plugin.


Why? Clazy is not part of our development philosophy. We should only do 
that
after there's a QUIP explaining which options in Clazy we use (which 
there

isn't).


Probably the QUIP shouldn't be about clazy /per se/, but about which 
coding practices we want to enforce via static analysis tooling.
clazy's current warning set could be used as a starting base for the 
discussion though, because it exists.



But more about that *later*! There's interesting things in the pipeline 
which KDAB would like to show first.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior 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

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

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 07:34:34 PDT, Sergio Martins escreveu:
> On 2017-05-04 14:53, Thiago Macieira wrote:
> > Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet
> > 
> > escreveu:
> >> Clang 4: Do we really need this to be tested with Linux in CI? If yes,
> >> then
> >> which configuration it will be replaced?
> > 
> > I don't think we need to. The macOS builds should be sufficient for
> > almost
> > everything intrinsic to Clang. Those of us who test it on Linux will
> > submit
> > fixes as needed.
> 
> We've introduced bugs in the past that would have been caught
> immediately by clang + Werror if it had been in the CI.
> clang has warnings that gcc doesn't have. Apple Clang is based on older
> clang (which one?), so doesn't have all the nice warnings.

I'm not doubting it has benefits. That's why I build with it on my machine. In 
fact, I build linux-clang more often than macx-clang or win32-msvc.

But Heikki's message implies it's not in the CI, so we're not losing anything 
we had. We're just not adding something we've never had.

> I don't know the cost of adding it to the CI, so I won't comment on the
> cost/benefit relation.

That's exactly the point. The question was: "what should it replace" and I 
don't think we can confidently say it should replace anything.

-- 
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] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Sergio Martins]

On 2017-05-04 14:53, Thiago Macieira wrote:
Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet 
escreveu:
Clang 4: Do we really need this to be tested with Linux in CI? If yes, 
then

which configuration it will be replaced?


I don't think we need to. The macOS builds should be sufficient for 
almost
everything intrinsic to Clang. Those of us who test it on Linux will 
submit

fixes as needed.


We've introduced bugs in the past that would have been caught 
immediately by clang + Werror if it had been in the CI.
clang has warnings that gcc doesn't have. Apple Clang is based on older 
clang (which one?), so doesn't have all the nice warnings.



I don't know the cost of adding it to the CI, so I won't comment on the 
cost/benefit relation.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior 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

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

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev 
escreveu:
> But we could have Linux clang configuration with clazy plugin.

Why? Clazy is not part of our development philosophy. We should only do that 
after there's a QUIP explaining which options in Clazy we use (which there 
isn't).

-- 
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] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Konstantin Tokarev]

04.05.2017, 16:53, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu:
>>  Clang 4: Do we really need this to be tested with Linux in CI? If yes, then
>>  which configuration it will be replaced?
>
> I don't think we need to. The macOS builds should be sufficient for almost
> everything intrinsic to Clang. Those of us who test it on Linux will submit
> fixes as needed.

But we could have Linux clang configuration with clazy plugin.

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

-- 
Regards,
Konstantin
___
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 - SUMMARY

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu:
> Clang 4: Do we really need this to be tested with Linux in CI? If yes, then
> which configuration it will be replaced?

I don't think we need to. The macOS builds should be sufficient for almost 
everything intrinsic to Clang. Those of us who test it on Linux will submit 
fixes as needed.

-- 
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] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Heikki Halmet]

Hi,

First of all thank you for all these comments!


There was few changes to the ‘proposal changes list’ and here is the summary:

32-bit iOS: will be dropped from CI and will be no longer supported by Qt
OSX 10.10: will be dropped from CI, but will be supported by Qt
GCC 7: When released it will be tested with some linux distro in CI
Clang 4: Do we really need this to be tested with Linux in CI? If yes, then 
which configuration it will be replaced?



Br
Heikki Halmet






-Original Message-
From: Development 
[mailto:development-bounces+heikki.halmet=qt...@qt-project.org] On Behalf Of 
Tuukka Turunen
Sent: 2. toukokuuta 2017 10:23
To: Jake Petroules ; Lars Knoll 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations 
changes


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