[Development] CI broken again?
Hi, I'm trying to push this patch: https://codereview.qt-project.org/#change,79826 but CI doesn't like me. Because CI seems to be based on luck, can CI folks give us a daily CI horoscopes forecast on this matter? E.g. if you are not born on the end of March and you don't have have only two android pending patches, then you are in luck ! :) Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI broken again?
On 05 Mar 2014, at 09:32, Rutledge Shawn shawn.rutle...@digia.com wrote: Sometimes though, we try to fix the autotests that fail the most frequently. If you can't reproduce the failure on your own machine, with the same OS, often the cause seems to be heavy multi-tasking on the CI machines, which will slow down timing-sensitive tests to the point of failure. But even that is hard to prove, since CI is a black box to most of us; and even if you get access to a CI machine to run tests on, they won't fail because it's not multi-tasking so heavily at that time. A virtual machine with very limited resources can often reproduce such test failures. At least VBox lets you change CPU execution cap while the virtual machine is running. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI broken again?
Hi, I'm trying to push this patch: https://codereview.qt-project.org/#change,79826 but CI doesn't like me. Because CI seems to be based on luck, can CI folks give us a daily CI horoscopes forecast on this matter? E.g. if you are not born on the end of March and you don't have have only two android pending patches, then you are in luck ! :) It's normal; if your patch cannot cause the failure then keep staging until it finally goes in. Sometimes though, we try to fix the autotests that fail the most frequently. If you can't reproduce the failure on your own machine, with the same OS, often the cause seems to be heavy multi-tasking on the CI machines, which will slow down timing-sensitive tests to the point of failure. But even that is hard to prove, since CI is a black box to most of us; and even if you get access to a CI machine to run tests on, they won't fail because it's not multi-tasking so heavily at that time. (And if it was, you'd have a problem to do anything interactively anyway.) You also can't add qDebugs or other types of verbosity to tests to try to debug CI failures because reviewers will say that tests should not be verbose. Well, I pushed again the submit button (after I said a little pray) and it fails in the same please (it seems God doesn't like me anymore). I really don't believe it has something to do with the heavy multi-tasking on the CI machines (or with God) ... to me it looks that the test is broken or something went in that make it breaks every time, but I wonder how that something got in, in the first place... BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI broken again?
Well, I pushed again the submit button (after I said a little pray) and it fails in the same please (it seems God doesn't like me anymore). I really don't believe it has something to do with the heavy multi-tasking on the CI machines (or with God) ... to me it looks that the test is broken or something went in that make it breaks every time, but I wonder how that something got in, in the first place... Usually CI error log will also show the latest changes that were staged when the failure took place. Have any of those changesets touched areas related to the tests case failure? Also, as Shawn mentioned, I have experienced a failure once with time sensitive test. Could be worth retrying a couple of times. HTH, -mandeep BogDan. ___ 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] Qt open source license in product
I have read something like below: Applications using Qt that use the open-source licenses need to follow the same license, so their source would need to be made available. We are using Qt Open source license under LGPL v2.1 + execption. Do we need to make our application source code available in this regard? Best Regards, Ramakanth DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Qt open source license in product
On 5 March 2014 10:13, Ramakanthreddy Kesireddy ramakanthreddy.kesire...@techmahindra.com wrote: I have read something like below: Applications using Qt that use the open-source licenses need to follow the same license, so their source would need to be made available. We are using Qt Open source license under LGPL v2.1 + execption. Do we need to make our application source code available in this regard? No. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt open source license in product
Hi, Disclaimer: IANAL No, the LGPL does not require the release of *sources* of your application. However, there are extra requirements to the *binaries* (especially related to being able to replace the Qt libraries you're providing). In general, if you're using Qt libs from a user accessible directory/source, you're likely ok. This is especially tricky on mobile - in my (IANAL) reading, Ministro is OK, but bundling the Qt libs within apps is a grey area at best unless you take extra precautions regarding the disclaimers/instructions. Best regards, Attila Csipa On 05/03/14 11:13, Ramakanthreddy Kesireddy wrote: I have read something like below: Applications using Qt that use the open-source licenses need to follow the same license, so their source would need to be made available. We are using Qt Open source license under LGPL v2.1 + execption. Do we need to make our application source code available in this regard? Best Regards, Ramakanth DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ___ 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] [Announce] Qt Creator 3.1 beta released
We are happy to announce the release of Qt Creator 3.1 beta: Blog: http://blog.qt.digia.com/blog/2014/03/04/qt-creator-3-1-beta-released/ Download: http://download.qt-project.org/development_releases/qtcreator/3.1/3.1.0-beta/ -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI broken again?
On 05.03.2014 10:11, BogDan wrote: Hi, Can you please share the link with us, personally I want to wait until that patch goes in. https://codereview.qt-project.org/79948 changes staged after 11:00 CET should not be rejected because of tst_bic (hopefully). -- Sergio Ahumada sahum...@blackberry.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: Qt open source license in product
On 05/03/14 11:19, Tomasz Siekierda sierd...@gmail.com wrote: On 5 March 2014 10:13, Ramakanthreddy Kesireddy ramakanthreddy.kesire...@techmahindra.com wrote: I have read something like below: Applications using Qt that use the open-source licenses need to follow the same license, so their source would need to be made available. We are using Qt Open source license under LGPL v2.1 + execption. Do we need to make our application source code available in this regard? No. You will find some information about licensing from http://qt-project.org/legal.html Whether or not you need to distribute the source code of your application as well as many other requirements depend on what you do and how you use Qt. If you are making a closed source product it is always recommended to perform full legal analysis to understand the needs. Yours, Tuukka ___ 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] Fwd: Qt open source license in product
Em qua 05 mar 2014, às 13:23:39, Turunen Tuukka escreveu: Whether or not you need to distribute the source code of your application as well as many other requirements depend on what you do and how you use Qt Please note that if you ship Qt, you need to distribute Qt's sources. The LGPL requires it. Strictly speaking, pointing to the Qt Project download site is not enough. If that website went away, you'd be left with the requirement towards everyone who received your application. So make sure you keep the sources for every Qt build you've shipped, for at least 5 years. Or make them available in a website. We're doing that at Intel: https://download.01.org/qt/source/ -- 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] Nominating Ulf Hermann as approver
+1 On 04 Mar 2014, at 13:51, Simon Hausmann simon.hausm...@digia.com wrote: Hi, I'd like to nominate Ulf for approvership. He's been hacking on various bits and pieces in the profiler support in Qml and he also implemented a brand new profiler for the JavaScript engine. I'm convinced that he would make a careful and responsible approver. Patches: https://codereview.qt-project.org/#q,owner:ulf.hermann%2540digia.com,n,z (don't forget the next button ;) And here's a list of him as a reviewer: https://codereview.qt-project.org/#q,reviewer:ulf.hermann%2540digia.com,n,z Any seconds? :) Simon ___ 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] Branches and time based releases
On 27/02/14 11:28, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: so to come back to the starting point: i think we should continue to target the release branch directly. the burden for the developers isn't very big (actually, one can even argue that the burden being there is a good thing ... it discourages people from pushing for release), and it makes the discussion about merging back irrelevant (because then it is both harmless and required). Agreed. excellent. to sum up: we agree with lars' proposal, except on this point. lars, feel like changing your mind? Ok, let’s try it and see what happens. We can always adjust as we go forward. Most other projects do however cherry-pick into their releases (that’s also what linux distributions do when they add patches to their packages). I still feel that this would make releasing easier, and I’m not sure the few duplicated commit would be a real issue in practice. Finding out whether something is part of a certain release could e.g. just as well be done on the gerrit tag instead of the git sha1. the next question would be how we proceed with implementing the change. i guess branching off 5.3 from stable and merging stable for the time being would be the best approach. retroactively creating the other branches (including dismantling release) is less important. the question is how quickly QA can set up the CI to match the new requirements (and ensure that future branching won't be a major PITA). we obviously shouldn't endanger the 5.3 release cycle, but *some* release is always in preparation, so just holding off doesn't buy us anything. I think we’re through the merge hazzle with stable now, so I’d keep that branch until 5.3.0. Once we have 5.3.0 out, let’s aim for renaming stable to 5.3 and move over to that. We should probably also retroactively create the 5.0 - 5.2 branches so we have something consistent. Cheers, Lars I truly believe that even our devs should land on the currently stable branch at first, not the development one. you didn't give good reasons for that position, though. Well, you disagreed with them. In my mind, my reasons are pretty good. They support my workflow of developing new features while at the same time testing the stable release and avoiding brokenness caused by others in dev. we have already established that this is not how most people work. you can do that only because you have a pretty good overview of what is happening in your module, and your work is mostly orthogonal to everything else going on. also, suggesting that the branch that the initial clone checks out will really determine what branch a thoughtful contributor targets is ... kinda far-fetched. The non-contributing developers, however, are the vast majority. Writing wiki pages isn't enough because people don't find them. It's amazing how many things are answered by a simple Google search, yet people don't do them. i don't buy that argument. laziness/stupidity should not be rewarded in an environment that is supposed to be productive. if a nice RTFM link is not good enough for somebody, they deserve losing time. You're not considering the time of people trying to help in #qt. Having to repeat ourselves over and over again, even if it's to say RTFM or give a link to lmgtfy.com, is tiresome. you will always have that in some way, no matter what initial branch you force on the people. it really doesn't get easier than having a canned response in form of an authoritative link. There are probably quite a few of those behind company firewalls who clone Qt and never tell us about it. I'd like to make sure they get the most stable version by default, when they clone. Better out-of-box experience. i so totally do not care about the out-of-the-box experience of git clones for *users* who don't even bother talking with anyone. they are not the target audience of this infrastructure, and optimizing for them is totally pointless. when i ask somebody to try a recent revision from git (typically in a bug report), i always name the branch as well, as that's the only way to be reasonably safe, irrespective of defaults. ___ 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
