Re: [Development] Proposals for changes to "Precheck" feature
On Friday, 25 March 2022 13:42:39 -03 Volker Hilsheimer wrote: > * always rebase the commit before prechecking > > Right now, precheck is a checkout, which means that the precheck is done on > top of the revision that it was pushed from. Since that is not the revision > that it will ultimately integrate against, this makes the precheck less > accurate. And it also ends up wasting CI resources if the precheck is done > for a leaf repo, with a revision that might have ancient dependencies. Then > qtbase etc from those dependency revisions might need to be rebuilt if they > are not in the artefact cache anymore. That's good... except when it isn't. When you have multiple changes you've submitted, you could pre-check the last one and get a result for all of them. That use-case will go away with rebasing. But that was already pretty limited. If you updated any of the previous changes, the pre-check would no longer work. I've resorted to pushing a dummy, WIP change with no reviewers and all my changes squashed, so I could pre-check that. In that case, I could rebase it at will too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updating x86 SIMD support in Qt
On 19/1/2022 1:01 PM, Thiago Macieira wrote: For Qt 6.4, I'd like to propose we change the way we detect and enable SIMD support. TL;DR: [snip] On a side track. Not knowing too much regarding simd, what would be the best benchmarks to get a comparison of Qt WebAssembly simd support vs. non simd (default)? 10 or 15 Particularly looking for speed ups or slow downs, as some wasm simd is native opcode provided by the browsers and others are emulated by emscripten. https://emscripten.org/docs/porting/simd.html ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposals for changes to "Precheck" feature
On 25/03/2022 17:54, Alexandru Croitor wrote: I would prefer a comment-based precheck system instead, and keep the existing precheck as-is. https://bugreports.qt.io/browse/QTQAINFRA-4419 See also the other ideas in that bug report, most notably also allowing to somehow select a subset of platforms. No need of waste energy at building a patch everywhere if I know that e.g. it's problematic only on a couple of platforms. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposals for changes to "Precheck" feature
Hi, > On 25. Mar 2022, at 17:42, Volker Hilsheimer wrote: > > * always rebase the commit before prechecking I have controversial feelings about this one. Sometimes i want it rebased on latest HEAD of the branch in question, sometimes I want the exact parent I chose. You can get merge conflicts during rebasing. Checking out will always succeed (even if later it might fail due to other reasons). I would prefer a comment-based precheck system instead, and keep the existing precheck as-is. https://bugreports.qt.io/browse/QTQAINFRA-4419 > * always test all platforms, don’t bail out on first failure I'd be happy with that, i often schedule my prechecks manually to ensure it doesn't fail on first try. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Proposals for changes to "Precheck" feature
Hey ho, We’ve had the convenient “precheck’” button in gerrit for a while now, allowing approvers to kick off a CI-dry-run to check if things would pass an integration before asking for reviews, and without the risk of tearing down a bunch of co-staged changes in case of failure. Two things that I think could be improved there, and I’d like your feedback to those: * always rebase the commit before prechecking Right now, precheck is a checkout, which means that the precheck is done on top of the revision that it was pushed from. Since that is not the revision that it will ultimately integrate against, this makes the precheck less accurate. And it also ends up wasting CI resources if the precheck is done for a leaf repo, with a revision that might have ancient dependencies. Then qtbase etc from those dependency revisions might need to be rebuilt if they are not in the artefact cache anymore. * always test all platforms, don’t bail out on first failure If I run a precheck, then I want to know about all the things that are wrong with my patch, not just the first thing. What do y’all think? Any other improvements we could make here? Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
