Re: [Development] NSURLConnection backend in 5.6.2

[Jake Petroules]

> On Sep 14, 2016, at 12:46 AM, Lars Knoll  wrote:
> 
> That’s the policy we have had all the time. No feature removal or additions, 
> no API changes in patch level releases. 
> 
> If a feature is really unused, or causes larger issues one can of course 
> discuss exceptions, but it should be a conscious decision involving the 
> relevant maintainers.

But we didn't remove a "feature", only a particular implementation detail of an 
existing feature, which should have no practical effect. I don't think that a 
rare combination of configure options now resulting in different behavior 
should really count as a feature change. The feature itself is "SSL support", 
which is unchanged.

Otherwise, any change to implementation details to fix bugs could theoretically 
be considered a feature removal or addition...

> 
> Cheers,
> Lars
> 
> 
> 
> 
> On 14/09/16 09:36, "Development on behalf of Morten Sorvig" 
>  morten.sor...@qt.io> wrote:
> 
>> Should we have a “no feature removal for cleanup reasons in patch
>> releases” policy? That’s easy to understand for everyone and we
>> don’t have to make the "is it obscure enough” judgement.
>> 
>> (The build failure could have been easily fixed so I don’t see
>> it as a relevant reason.)
>> 
>> Morten
>> 
>> 
>> 
>>> On 13 Sep 2016, at 20:33, Jake Petroules  wrote:
>>> 
>>> Because the APIs are deprecated by Apple so they would have had to be 
>>> removed/changed soon anyways, especially when an alternative (which is the 
>>> default now) is already available. Also it caused build failure on 
>>> tvOS/watchOS.
>>> 
 On Sep 13, 2016, at 11:25 AM, Thiago Macieira  
 wrote:
 
 The changelog contains this entry:
 
 - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has
  been removed, since SecureTransport is the default SSL backend on iOS
  and is enabled by default. This means that building with -no-openssl
  -no-securetransport will no longer provide SSL capabilities on iOS.
 
 WTH? Why are we removing options in a patch release? What happened?
 
 Is the backend so severely broken that it needed to be removed?
 -- 
 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
>>> 
>>> -- 
>>> Jake Petroules - jake.petrou...@qt.io
>>> Consulting Services Engineer - The Qt Company
>>> Qbs build tool evangelist - qbs.io
>>> 
>>> ___
>>> 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

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] Boot2Qt Device Utilities module repo

[Shawn Rutledge]

> On 14 Sep 2016, at 15:45, Frederik Gladhorn  wrote:
> 
> On fredag 9. september 2016 12.04.57 CEST Kimmo Ollila wrote:
>> Hi All,
>> 
>> We are planning to open new Boot2Qt Device Utilities module repository.
>> Qt Device Utilities module allows user manipulate easily various embedded
>> device settings via simple QML APIs.
>> 
>> More information can be found at the end of the blog post below:
>> https://blog.qt.io/blog/2016/06/16/qt-5-7-for-device-creation/
>> 
>> I also want to propose Teemu Holappa to be the maintainer of Boot2Qt Device
>> Utilities since he is the one who implemented the module.
> 
> There was no opposition to this mail, so I'll create qt/qtdeviceutilities in 
> gerrit.

Sorry I didn’t notice your post the first time, and also hadn’t gotten around 
to reading the blog post until now.

But it looks like there is some overlap with the qtsystems module.  Maybe it 
would be a good time to combine efforts and try to get that module up to snuff 
instead of starting over?

It’s not the first connman Qt binding either, although that’s not in qtsystems 
so far.  I’ve been using this https://git.merproject.org/mer-core/libconnman-qt 
on one personal project.

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

Re: [Development] Boot2Qt Device Utilities module repo

[Frederik Gladhorn]

On fredag 9. september 2016 12.04.57 CEST Kimmo Ollila wrote:
> Hi All,
> 
> We are planning to open new Boot2Qt Device Utilities module repository.
> Qt Device Utilities module allows user manipulate easily various embedded
> device settings via simple QML APIs.
> 
> More information can be found at the end of the blog post below:
> https://blog.qt.io/blog/2016/06/16/qt-5-7-for-device-creation/
> 
> I also want to propose Teemu Holappa to be the maintainer of Boot2Qt Device
> Utilities since he is the one who implemented the module.

There was no opposition to this mail, so I'll create qt/qtdeviceutilities in 
gerrit.

Cheers,
Frederik


> 
> Br,
> Kimmo Ollila
> 
> The Qt Company
> Email: kimmo.oll...@qt.io
> Mobile: + 358 50 590 9774
> http://qt.io
> --
> PRIVACY AND CONFIDENTIALITY NOTICE
> This message and any attachments are intended only for use by the named
> addressee and may contain privileged and/or confidential information. If
> you are not the named addressee you should not disseminate, copy or take
> any action in reliance on it. If you have received this message in error,
> please contact the sender immediately and delete the message and any
> attachments accompanying it. Digia Plc does not accept liability for any
> corruption, interception, amendment, tampering or viruses occurring to this
> message. -


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 13/09/16 22:29, Christian Kandeler wrote:

Stephen Kelly wrote:


There is no input file. There is only an input number. The task is from
Bo, who gave it as a simplified example.

Oops, I'm wrong here. Bo said to read the number from a file.
I don't think that changes anything though regarding dynamic build graph
being an advantage.

Sure?

It is trivial:

 https://github.com/ske-ableton/generated-build-inputs/commit/d4ef3c48

Clearly there is some kind of misunderstanding happening here. In 
particular, when I said 'advantage' above, it means 'Qbs can do this 
thing, but CMake can not'.



What about the (lack of) need for two rules to agree in advance about the 
location of a generated file?


I don't know what you are talking about. I don't know what rules have to 
'agree'.



Also, there could be several layers of indirection, with the second set of 
generated files also containing meta data etc.


Please post example code for that. Feel free to start by forking my repo.


You quoted and challenged just one small part of my email. Can you 
answer the rest of it? I want to understand Qbs and what it can do with 
a dynamic build graph which CMake can't do. I made a guess in my email 
in the hope that you would confirm that my assumption is correct, or 
would correct my assumption to fill my understanding.


Thanks,

--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

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

Re: [Development] NSURLConnection backend in 5.6.2

[Morten Sorvig]

> On 13 Sep 2016, at 20:41, Jake Petroules  wrote:
> 
> 
>> On Sep 13, 2016, at 11:40 AM, Konstantin Tokarev  wrote:
>> 
>> 
>> 
>> 13.09.2016, 21:33, "Jake Petroules" :
>>>  Because the APIs are deprecated by Apple so they would have had to be 
>>> removed/changed soon anyways, especially when an alternative (which is the 
>>> default now) is already available.
>> 
>> AFAIK they cannot remove API from released SDK, and users may choose to use 
>> it even if it's not latest and greatest anymore.
> 
> They can and have before. 

I don’t think I’ve seen this happen, unless you were referring to
the 32->64bit transition. If you grep for NS_DEPRECATED in the headers
there are plenty of references to API that has been deprecated for a
long time.

What are the counter-examples?

Morten


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

Re: [Development] NSURLConnection backend in 5.6.2

[Lars Knoll]

That’s the policy we have had all the time. No feature removal or additions, no 
API changes in patch level releases. 

If a feature is really unused, or causes larger issues one can of course 
discuss exceptions, but it should be a conscious decision involving the 
relevant maintainers.

Cheers,
Lars




On 14/09/16 09:36, "Development on behalf of Morten Sorvig" 
 wrote:

>Should we have a “no feature removal for cleanup reasons in patch
>releases” policy? That’s easy to understand for everyone and we
>don’t have to make the "is it obscure enough” judgement.
>
>(The build failure could have been easily fixed so I don’t see
>it as a relevant reason.)
>
>Morten
>
>
>
>> On 13 Sep 2016, at 20:33, Jake Petroules  wrote:
>> 
>> Because the APIs are deprecated by Apple so they would have had to be 
>> removed/changed soon anyways, especially when an alternative (which is the 
>> default now) is already available. Also it caused build failure on 
>> tvOS/watchOS.
>> 
>>> On Sep 13, 2016, at 11:25 AM, Thiago Macieira  
>>> wrote:
>>> 
>>> The changelog contains this entry:
>>> 
>>> - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has
>>>   been removed, since SecureTransport is the default SSL backend on iOS
>>>   and is enabled by default. This means that building with -no-openssl
>>>   -no-securetransport will no longer provide SSL capabilities on iOS.
>>> 
>>> WTH? Why are we removing options in a patch release? What happened?
>>> 
>>> Is the backend so severely broken that it needed to be removed?
>>> -- 
>>> 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
>> 
>> -- 
>> Jake Petroules - jake.petrou...@qt.io
>> Consulting Services Engineer - The Qt Company
>> Qbs build tool evangelist - qbs.io
>> 
>> ___
>> 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] NSURLConnection backend in 5.6.2

[Morten Sorvig]

Should we have a “no feature removal for cleanup reasons in patch
releases” policy? That’s easy to understand for everyone and we
don’t have to make the "is it obscure enough” judgement.

(The build failure could have been easily fixed so I don’t see
it as a relevant reason.)

Morten



> On 13 Sep 2016, at 20:33, Jake Petroules  wrote:
> 
> Because the APIs are deprecated by Apple so they would have had to be 
> removed/changed soon anyways, especially when an alternative (which is the 
> default now) is already available. Also it caused build failure on 
> tvOS/watchOS.
> 
>> On Sep 13, 2016, at 11:25 AM, Thiago Macieira  
>> wrote:
>> 
>> The changelog contains this entry:
>> 
>> - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has
>>   been removed, since SecureTransport is the default SSL backend on iOS
>>   and is enabled by default. This means that building with -no-openssl
>>   -no-securetransport will no longer provide SSL capabilities on iOS.
>> 
>> WTH? Why are we removing options in a patch release? What happened?
>> 
>> Is the backend so severely broken that it needed to be removed?
>> -- 
>> 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
> 
> -- 
> Jake Petroules - jake.petrou...@qt.io
> Consulting Services Engineer - The Qt Company
> Qbs build tool evangelist - qbs.io
> 
> ___
> 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