Re: [Development] [RFC] more gerrit codereview scores?
Not currently. It just doesn't work in the current CI system. But we're currently working on a new and much improved CI system (more info soon in a separate mail), that should at least improve the long integration times. Cheers, Lars On 19/03/15 04:10, Konstantin Ritt ritt...@gmail.commailto:ritt...@gmail.com wrote: [Not really in-topic but still...] Can we also introduce a flag with meaning like this change doesn't require clean build? For example, when the approver gives his +2 to a simple change in the .h file, he can also turn that flag on -- iff all staged changes has this flag on, then CI does incremental build and runs auto-tests as usual. Konstantin 2015-03-09 11:30 GMT+04:00 Knoll Lars lars.kn...@theqtcompany.commailto:lars.kn...@theqtcompany.com: On 07/03/15 04:03, Thiago Macieira thiago.macie...@intel.commailto:thiago.macie...@intel.com wrote: On Friday 06 March 2015 17:42:00 Oswald Buddenhagen wrote: 1) i'd like to propose the introduction of the code review score -3. -1: I would prefer this is not merged as is, advisory, non-sticky -2: This shall not be merged as is, blocking, non-sticky -3: This shall not be merged [at all], blocking, sticky Agreed, this makes sense. The -1 means if someone approves, ignore me, whereas -2 means this needs to change, can't be merged. The -3 is just to indicate an approach that can never work, such as a feature we cannot accept or a patch submitted to the wrong branch. -2 are already rather rare, so I expect -3 to be used only once in a blue moon. Agree, it would be nice to have a non sticky -2, so the sticky -3 makes sense. 2) i'd like to propose the introduction of the code review score +3. let's start with the scores: +3: Looks good to me, approved, enabling +2: Looks good to me, but someone else must approve, advisory +1: Someone else must review this, advisory possible uses: - non-approvers (specifically, not-yet-approvers) would have two levels to express their opinion You mean four levels, since they also get -1 and 0. - the new +1 gives the possibility to explicitly give a neutral score (substitute for +0, which gerrit does not permit) - *maybe* some approvers would feel less inclined to approve changes they don't fully understand (yes, this is actually a problem), simply because of the psychological effect of the possibility to express the opinion with more numerical nuance. i don't feel very strongly about this one, but i think it would add value. I don't like this one. If you don't want to express an opinion, leave your score at 0. I don't see the need to have a value saying I've reviewed but have no opinion. I also don't see why approvers are giving +2 if they don't fully understand it. Not only should they be using the right value for that, this change wouldn't help in any way since they could just turn around and give +3 to changes they don't fully understand. As a drawback, it would make Qt's Gerrit behave very differently from everyone else, where a +2 does mean approval. In my opinion, this change has no pros and has cons. While I see the reasoning behind, I think this overcomplicates things. A non-sticky -2 that balances a +2 should be enough to solve most of the issues, and the proposed +1 sounds very much like the current +0 to me, so we can IMO just as well leave it out. Cheers, Lars ___ Development mailing list Development@qt-project.orgmailto: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] [Mac] tst_qquickwindow::testWindowVisibilityOrder() regression
Hi. I'll have a look. Best regards, Timur. From: development-bounces+timur.pocheptsov=theqtcompany@qt-project.org development-bounces+timur.pocheptsov=theqtcompany@qt-project.org on behalf of Albert Astals Cid albert.ast...@canonical.com Sent: Thursday, March 19, 2015 9:53 AM To: development@qt-project.org Subject: [Development] [Mac] tst_qquickwindow::testWindowVisibilityOrder() regression It seems tst_qquickwindow::testWindowVisibilityOrder() has regressed in the 5.4 branch (either because of qtdeclarative or qtbase changes) and is not letting changes to the branch integrate. I've run it locally here (linux) and get no failure, so it may be Mac specific since it always seem to fail in the Mac builder. Can anyone with a Mac please have a look? http://testresults.qt.io/ci/QtDeclarative_5.4_Integration/build_00605/macx-clang_developer-build_qtnamespace_OSX_10.7/log.txt.gz Cheers, Albert ___ 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] [Mac] tst_qquickwindow::testWindowVisibilityOrder() regression
For me this test fails with 5.4 and passes with 5.5, so something was fixed :) (the test code is the same, of course). Best regards, Timur. From: development-bounces+timur.pocheptsov=theqtcompany@qt-project.org development-bounces+timur.pocheptsov=theqtcompany@qt-project.org on behalf of Albert Astals Cid albert.ast...@canonical.com Sent: Thursday, March 19, 2015 9:53 AM To: development@qt-project.org Subject: [Development] [Mac] tst_qquickwindow::testWindowVisibilityOrder() regression It seems tst_qquickwindow::testWindowVisibilityOrder() has regressed in the 5.4 branch (either because of qtdeclarative or qtbase changes) and is not letting changes to the branch integrate. I've run it locally here (linux) and get no failure, so it may be Mac specific since it always seem to fail in the Mac builder. Can anyone with a Mac please have a look? http://testresults.qt.io/ci/QtDeclarative_5.4_Integration/build_00605/macx-clang_developer-build_qtnamespace_OSX_10.7/log.txt.gz Cheers, Albert ___ 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] [Mac] tst_qquickwindow::testWindowVisibilityOrder() regression
It seems tst_qquickwindow::testWindowVisibilityOrder() has regressed in the 5.4 branch (either because of qtdeclarative or qtbase changes) and is not letting changes to the branch integrate. I've run it locally here (linux) and get no failure, so it may be Mac specific since it always seem to fail in the Mac builder. Can anyone with a Mac please have a look? http://testresults.qt.io/ci/QtDeclarative_5.4_Integration/build_00605/macx-clang_developer-build_qtnamespace_OSX_10.7/log.txt.gz Cheers, Albert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Changes to continuous integration in qtdeclarative/dev
Hi all, I'd like to give everyone a heads up (of hopefully good news). We plan to switch over the dev branch of qtdeclarative to a new continuous integration system in the beginning of next week. We currently aim for Monday if all goes well. There will be a more comprehensive blog post about the new system in the near future, but it seems only fair to give a short intro here. One goal is to take advantage of the modularization which has been done on a per module level in Qt, but is so far only partially reflected in the continuous integration system. In order to cut out long waiting times for git checkouts, we will create source tar balls centrally using git archive which are then downloaded by the build agents. Agents are clones of virtual machine snapshots, so they should always be in a good shape, runs should be much more reproducible (apart from system clock and network dependencies). Once a module is built, we save the build artifacts (the build library binaries etc) and then reuse the build artifacts for the modules depending on it. This way we do not rebuild qtbase for qtdeclarative, unless it changed since the last run. There is still a lot of potential for optimization at this stage, but first we want the system to be reliable. We should be covering all platforms/operating systems/configurations that we are currently running in the CI, but it would be great if everyone working on the module could have an eye on the test logs, in case we did miss something. One feature we will no longer support are reverse dependencies. After many long discussions we concluded that the best way forward is to have fast turnaround times (potentially reverting patches quicker if they are found to block other modules, until they have been fixed) combined with frequent builds of all modules (at least daily, probably more often). If you run into trouble or see suspicious behavior, talk to Simon, Lars and me, we'll all be keeping an eye on things running smoothly. Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] image format plugins
2015-03-19 8:42 GMT+04:00 Thiago Macieira thiago.macie...@intel.com: On Thursday 19 March 2015 04:54:09 Konstantin Ritt wrote: Hi guys. What do you think about moving gif and ico plugins from qtbase to qtimageformats? Why? What's the reason? Well, we have a separate module for non-mandatory image format plugins - so why not having them in a single place? Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] image format plugins
On Thursday 19 March 2015 15:05:38 Konstantin Ritt wrote: 2015-03-19 8:42 GMT+04:00 Thiago Macieira thiago.macie...@intel.com: On Thursday 19 March 2015 04:54:09 Konstantin Ritt wrote: Hi guys. What do you think about moving gif and ico plugins from qtbase to qtimageformats? Why? What's the reason? Well, we have a separate module for non-mandatory image format plugins - so why not having them in a single place? Your premise is incorrect. It's not about non-mandatory. So, what's the reason we should do it? -- 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] image format plugins
On Thursday 19 March 2015 19:30:40 Konstantin Ritt wrote: I didn't say we *should* do it. Simply asking for opinions. There is no any single .ico file in qtbase (except of ones in qicoimageformat auto-test) and we don't support -no-ico/-qt-ico/-plugin-ico configure options, which makes it a good candidate. There are plenty of icons on websites (favicon.ico), which is why the ICO engine was placed in Qt in the first place. In addition, there's no third-party library required, this is all Qt-based code. I don't see why it should be disabled at all. There is also just a single .gif file in widgets/movie example, though we support -no-gif configure option and widgets/movie example never checks if gif format is really supported. ^ So why bloating qtbase? Removing the files will not make the repository smaller. The actual checkout size for most people will also be the same, since we're not proposing removing from Qt, just moving around. -- 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] image format plugins
On Mar 19, 2015, at 21:57, Thiago Macieira thiago.macie...@intel.com wrote: On Thursday 19 March 2015 19:30:40 Konstantin Ritt wrote: I didn't say we *should* do it. Simply asking for opinions. There is no any single .ico file in qtbase (except of ones in qicoimageformat auto-test) and we don't support -no-ico/-qt-ico/-plugin-ico configure options, which makes it a good candidate. There are plenty of icons on websites (favicon.ico), which is why the ICO engine was placed in Qt in the first place. In addition, there's no third-party library required, this is all Qt-based code. I don't see why it should be disabled at all. There is also just a single .gif file in widgets/movie example, though we support -no-gif configure option and widgets/movie example never checks if gif format is really supported. ^ So why bloating qtbase? Removing the files will not make the repository smaller. The actual checkout size for most people will also be the same, since we're not proposing removing from Qt, just moving around. Several years ago I started writing a giflib-based plugin with features that the existing one doesn’t have (to read and write text comments in the gif file was what I wanted, but probably giflib can do a few more things too). If I was to get it integrated, where should it live? It would need a config option, because of depending on a system library: the existing plugin is better if you don’t have giflib, or don’t want the dependency. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] image format plugins
On Thursday 19 March 2015 21:13:42 Rutledge Shawn wrote: Removing the files will not make the repository smaller. The actual checkout size for most people will also be the same, since we're not proposing removing from Qt, just moving around. Several years ago I started writing a giflib-based plugin with features that the existing one doesn’t have (to read and write text comments in the gif file was what I wanted, but probably giflib can do a few more things too). If I was to get it integrated, where should it live? It would need a config option, because of depending on a system library: the existing plugin is better if you don’t have giflib, or don’t want the dependency. We shouldn't have two plugins, so you should merge your code into the existing plugin, even if it's two different .cpp files selected by qmake magic. And I'd say that any configuration besides simple automatic detection should be restricted to qtbase source code. So I'd say your expanded plugin should remain in qtbase. -- 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] image format plugins
2015-03-19 18:23 GMT+04:00 Thiago Macieira thiago.macie...@intel.com: On Thursday 19 March 2015 15:05:38 Konstantin Ritt wrote: 2015-03-19 8:42 GMT+04:00 Thiago Macieira thiago.macie...@intel.com: On Thursday 19 March 2015 04:54:09 Konstantin Ritt wrote: Hi guys. What do you think about moving gif and ico plugins from qtbase to qtimageformats? Why? What's the reason? Well, we have a separate module for non-mandatory image format plugins - so why not having them in a single place? Your premise is incorrect. It's not about non-mandatory. So, what's the reason we should do it? I didn't say we *should* do it. Simply asking for opinions. There is no any single .ico file in qtbase (except of ones in qicoimageformat auto-test) and we don't support -no-ico/-qt-ico/-plugin-ico configure options, which makes it a good candidate. There is also just a single .gif file in widgets/movie example, though we support -no-gif configure option and widgets/movie example never checks if gif format is really supported. ^ So why bloating qtbase? Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
