[Development] QBS module git cloning

[Ernst Maurer]

Each time, when I'm trying to clone qt creator I'm getting the error
related with QBS
 (I'm not an active developer, and I do this probably monthly)
Do I something wrong? because it happens always when I'm trying to get
creator from git

*Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git
) registered for path
'src/shared/qbs'*

*Cloning into 'src/shared/qbs'...*

*error: Failed connect to code.qt.io:80 ; No error
(curl_result = 7, http_code = 0, sha1 =
e1d5dc0b836dc6f709b2deeff2d0051d03b2c135)*

*error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under
http://code.qt.io/cgit/qt-labs/qbs.git
*
*Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53*
*while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0.*
*error: Fetch failed.*
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCon session notes

[Edward Welbourne]

> Also put the notes to the Wiki https://wiki.qt.io/Qt_contributors_summit_2016

Suggestion: let's use the features of the tool to do the work.  Add
[[Category:QtCS2016]] to any pages related to this, and we can just turn
the page above into the category over-view page (with a redirect,
naturally).  That way, you just have to set the category on your page,
you don't have to also edit the page that needs to link to it.

Use the strengths of the tool to our advantage ...

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

[Development] Qt 5.8 API review (vs 5.7.0)

[Edward Welbourne]

Hi all,

It's that time in the release cycle again - API review time.
If you can catch a moment when Gerrit isn't hiding, please
take a look at any modules you care for:

https://codereview.qt-project.org/170634 -- qtbase
https://codereview.qt-project.org/170635 -- qtdeclarative
https://codereview.qt-project.org/170636 -- qtactiveqt
https://codereview.qt-project.org/170637 -- qtmultimedia
https://codereview.qt-project.org/170638 -- qttools
https://codereview.qt-project.org/170639 -- qtlocation
https://codereview.qt-project.org/170640 -- qtconnectivity
https://codereview.qt-project.org/170641 -- qtwayland
https://codereview.qt-project.org/170642 -- qt3d
https://codereview.qt-project.org/170643 -- qtserialbus
https://codereview.qt-project.org/170644 -- qtserialport
https://codereview.qt-project.org/170645 -- qtandroidextras
https://codereview.qt-project.org/170646 -- qtwebsockets
https://codereview.qt-project.org/170647 -- qtwebengine
https://codereview.qt-project.org/170648 -- qtcanvas3d
https://codereview.qt-project.org/170649 -- qtcharts
https://codereview.qt-project.org/170650 -- qtdatavis3d
https://codereview.qt-project.org/170651 -- qtvirtualkeyboard
https://codereview.qt-project.org/170652 -- qtscxml

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

[Development] Gerrit down

[Frederik Gladhorn]

Hi all,

gerrit (codereview.qt-project.org) is going to be down over the weekend, 
unless we find out what is currently causing trouble in it. Currently it seems 
to stop working every few hours and the root cause is unclear.

Sorry for the disturbance :(

Cheers,
Frederik

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

Re: [Development] Gerrit down

[Frederik Gladhorn]

Since the problem is very likely something with the mail setup being broken, 
we'll disable gerrit mails - so expect not to see any emails from gerrit until 
this is fixed. Occasional mail might still make it, we'll try giving mails a 
short timeout before dropping them.
The other choice to completely not have gerrit running seems even worse.

Have a good weekend!
Frederik

On fredag 9. september 2016 16.17.14 CEST you wrote:
> Hi all,
> 
> gerrit (codereview.qt-project.org) is going to be down over the weekend,
> unless we find out what is currently causing trouble in it. Currently it
> seems to stop working every few hours and the root cause is unclear.
> 
> Sorry for the disturbance :(
> 
> Cheers,
> Frederik


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

Re: [Development] QUuid documentation

[Edward Welbourne]

Benjamin Terrier:
>> However, my knowledge is that whatever the method one use to generate
>> your UUID, one can never guarantee its uniqueness. Meaning that the
>> Qt documentation is falsely guarantying unique UUID and therefore
>> should be changed.
>>
>> If anyone can confirm, I'll create a bug report.

Thiago Macieira
> Right, it's not guaranteed. It's just that the chance of collision is
> virtually zero.

... and for sufficiently small values of "virtually zero", that's as
close a guarantee as you'll get to anything, because no matter how well
you think you can guarantee things, cosmic rays still sporadically flip
bits in your memory.

I read a most illuminating paper a few years back that looked at the
reliability of tests of prime-ness for large numbers.  There's a widely
used approach that's cheap and theoretically not guaranteed but easy to
apply to enough test-cases to reduce the likelihood of error to
ignorably low.  This was compared to the best known "provably correct"
algorithm for determining primeness - which is significantly more
computationally expensive.  Due to the (ridiculously rare) flipping of
bits by cosmic rays hitting the processor and memory, the latter was in
fact *less* reliable than the former, because the former ran faster so
incurred a smaller chance of errors due to stray rays.

I don't think we should worry about documenting how not-quite-perfect
our guarantee of UID uniqueness is in a case where - realistically -
the difference from perfection is ignorable.

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

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

[Jake Petroules]

I just found a perfect example of how hard building a JAR file is in qmake for 
example, compared to qbs:



qbs-javac-scan.pro
Description: qbs-javac-scan.pro


qbs-javac-scan.qbs
Description: qbs-javac-scan.qbs
And the qmake version technically doesn't even handle dependencies properly (e.g. removing an anonymous inner class will still result in the corresponding (stale) class file being included in the JAR file).On Sep 8, 2016, at 9:16 AM, Jake Petroules  wrote:



Another thing that's very hard to do in other build systems is building Java code. The class files emitted by a Java compiler actually vary depending on the contents of the Java files themselves.


Imagine you've built a JAR file, and then you add a new anonymous inner class within one of your Java source files. The command line invocation to build the JAR file needs to be updated to contain the new class file that will result. Impossible
 with qmake/CMake/Makefiles/etc.


Whereas Qbs has sophisticated support exactly for this case: https://github.com/qt-labs/qbs/tree/master/share/qbs/modules/java, made possible by its dynamic
 build graph.



On Sep 8, 2016, at 6:52 AM, Bo Thorsen  wrote:


Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev:

> The only problem is that you have to run moc on each of the .h files.

Run moc from inside script when you generate header.


Yes, I thought about that at the time as well. While simple enpough, there are some complications. You would have to run moc exactly like if it was done by the qmake built makefiles, with exactly the same environment and arguments. Not impossible, but it does
 sound brittle. For example different qmake versions might do things differently.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
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 listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
-- Jake Petroules - jake.petrou...@qt.ioConsulting Services Engineer - The Qt CompanyQbs build tool evangelist - qbs.io

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

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

[Kevin Kofler]

Jake Petroules wrote:
> Another thing that's very hard to do in other build systems is building
> Java code. The class files emitted by a Java compiler actually vary
> depending on the contents of the Java files themselves.
> 
> Imagine you've built a JAR file, and then you add a new anonymous inner
> class within one of your Java source files. The command line invocation to
> build the JAR file needs to be updated to contain the new class file that
> will result. Impossible with qmake/CMake/Makefiles/etc.

Well, what you can do if you have a lot of Java stuff to build is to just 
shell out to Ant. That's how Qt Jambi does it, for example. Use the right 
tool for the job.

CMake has some support for building Java, but indeed, it does not 
automatically figure out the outputs of each .java file for you. Dedicated 
Java build systems are much better at that.

Kevin Kofler

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

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

[Kevin Kofler]

Bo Thorsen wrote:
> I'm sure there are ways you can make the build call cmake or force a
> build to fail and rebuild, and that's what you can currently do. And
> those all feels annoying when you work on the project.

Well, that's what CMake does by itself whenever it sees that it's needed (or 
at least thinks it is), e.g., if you upgraded some dependency. E.g., I've 
seen the CMake-produced makefiles auto-rerun CMake on my projects after 
upgrading Qt. Thankfully, CMake is so fast (due to being native C++ code) 
that it is barely noticeable.

Kevin Kofler

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

[Development] Boot2Qt Device Utilities module repo

[Kimmo Ollila]

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.

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 "Managing Qt's branches" session @ QCS 2016

[Lars Knoll]

On 08/09/16 17:13, "Development on behalf of Thiago Macieira" 
 wrote:

>On quinta-feira, 8 de setembro de 2016 07:37:28 PDT Liang Qi wrote:
>> Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
>> that? 5.7.1 is very soon in a few weeks. There will be a few months gap
>> between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
>> sometimes it's not tested enough in user(or application developers) side,
>> so some regressions or a bit critical issues will be found between 5.8.0
>> and 5.8.1. It's good for users to have a more stable release of 5.7.2.
>> 
>> If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
>> Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.
>> 
>> And I would like to see it becomes a convention for future releases.
>
>It wouldn't be bad, if the release team and merging team can make it work. Our 
>concern was that you and Eddy are spending far too much time on doing merges.

It’s basically a question about how we can deal most efficiently with the 
branches we have. And both merging and cherry-picking are valid ways to work 
with those branches.

If the branches are closely related, merging is obviously the better choice, as 
conflicts will be rare. But once branches start diverging more, merging will at 
some point start to create more overhead (and risk) than cherry-picking back 
into the older branch.

There are several reasons, why I think we at some point should stop merging 
from 5.6 to newer branches. 

We are doing significant changes all through our code base currently. C++11 and 
configuration system related changes are just one example. This will lead to 
more and more merge conflicts as time goes by. I’ve already reviewed a few 
merges where it took significant effort to verify that the merge was correct. 
Merges are done by one person, and that person often doesn’t know all the 
details of what the patch causing a conflict is trying to achieve. This 
actually increases our risk of introducing regressions into our newer branches.

Having a lot of branches also increases the complexity for all of us into 
figuring out where a change should go. In many cases it also does significantly 
increase turn-around time if a patch is needed in a newer branch. Having a long 
merge patch from 5.6 to dev can cause delays for all of us. If those delays get 
too long, this is costly for all of us and will slow us down when developing 
new features.

A cherry-picking approach for the LTS branch can make sense, as it distributes 
the burden of bringing the bug fix to both the stable and LTS branch over all 
developers and doesn’t put it on the one person having to do the merges. It 
will also help limiting changes in the LTS branch to the things that should 
really go there.

Cheers,
Lars

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