Re: [Development] New features in CI
Il 01/03/21 14:25, Lars Knoll ha scritto: First of all, you can now find a ‘Precheck' button in gerrit. That button triggers a full CI test run of the Sha1 in the change and will post back the result of that run as a comment. This should make it a lot easier to test some of your changes before manual reviews start or at any other time when you need them. But please be aware that those runs do consume resources from the CI system, so you shouldn’t just hit that button for anything. Thank you so much for this. I can finally stop pestering people just to ask for a CI dry run! -- 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: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New features in CI
Am 01.03.21 um 14:25 schrieb Lars Knoll: Hi all, While the CI maintenance break today took a little longer than usual, it also came with two very nice new features that will hopefully make everybody’s life easier. First of all, you can now find a ‘Precheck' button in gerrit. That button triggers a full CI test run of the Sha1 in the change and will post back the result of that run as a comment. This should make it a lot easier to test some of your changes before manual reviews start or at any other time when you need them. But please be aware that those runs do consume resources from the CI system, so you shouldn’t just hit that button for anything. Secondly, we have now added a new mode on how CI integrations work. So far all changes that got staged since the last CI run would be tested together. This had the downside that we would be testing a large amount of independent changes together in one CI run. If one of those changes had a problem, all changes would get rejected. Worse, many people would then simply hit the ‘Stage’ button once again assuming it wasn’t their change that caused the problem. You probably have all experienced this in some form or another. To fix this, we have now added a new feature (called parallel staging branches), where CI rounds are not serialised anymore. Instead, COIN will start a new CI run 15 minutes after a change (or a set of changes) got staged. It will start that run independently of whether another CI run is currently happening. If a staging branch passes, all the changes contained in that branch will be merged into the target branch (can be a fast-forward merge). If the merge produces a conflict, the staging branch will get rejected even if it passed CI. This means that COIN will usually only test changes that are being staged together. The advantages are that you can more easily pin down a change that caused a CI failure, and that your changes will not get rejected because a buggy change got staged in the same CI run (at least it’s a lot less likely). The one drawback is that we can in some rare cases end up with a repository in a state where two staging branches passed CI and didn’t conflict when merging them, but the merged state does not pass CI anymore for some reason. In that case the branch will be blocked until someone stages a fix for the problem. But we do expect this to happen rather seldom, so I do believe that the benefits far outweigh the drawback. Will the CI autodetect such a situation? Will it create a suitable alert? For now this feature is only enabled in qtbase/dev, but if it works out well, we will most likely enable it for further repositories and branches. Last, but not least I’d like to thanks Toni Saario and Jukka Jokiniva for doing all the the hard work :) Enjoy! Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fate of fixqt4headers.pl in Qt6
On 3/1/21 10:03 AM, Edward Welbourne wrote: Can fixqt4headers.pl be removed from Qt6? Seems sane to me. One less perl script ... Here we go: https://codereview.qt-project.org/c/qt/qtbase/+/336822 Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fate of fixqt4headers.pl in Qt6
Joerg Bornemann (26 February 2021 16:07) > I noticed that we still have fixqt4headers.pl in our bin directory. > For the uninitiated, this is it's documentation: > https://doc.qt.io/qt-5/portingcppapp.html > > That page is already gone in Qt6. > > Can fixqt4headers.pl be removed from Qt6? Seems sane to me. One less perl script ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Monthly CI maintenance break - March (Mon 1st Mar 2021)
Hi, It seems that 6 hours was not enough, so maintenance break is still ongoing with no estimated time of completion. We will let you know when it is done. VP From: Ville-Pekka Karhu Sent: Monday, February 22, 2021 3:55 PM To: Qt development mailing list Subject: Monthly CI maintenance break - March (Mon 1st Mar 2021) Hi all! We’ll have our scheduled maintenance break on next Monday (1st of Mar). We’ll begin our work at 6:00 UTC and you can prepare for 6 hours of CI not working. Br, VP ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaType::NeedsConstruction vs QTypeInfo::isComplex
On 01/03/2021 11:45, Fabian Kosmale wrote: currently we promise that if for a type its QMetaType does not have the NeedsConstruction flag set, it can be initialized with memzero. We set that flag if the type is complex according to QTypeInfo. However, after the discussion inhttps://lists.qt-project.org/pipermail/development/2020-November/040546.html, primitive types are not complex, but only guarantee that they can be memcpyed not memzeroed. Therefore either the implementation or the documentation of NeedsConstruction needs to change (note that Qt itself does not use that flag anywhere as far as I can tell). But which of those two options should we choose? What are the actual use-cases of that flag anyway? Well, one of the outcomes of that discussion is that we can't at the same time - assume that trivial types are PRIMITIVE, and - zero-initialize PRIMITIVE types because of things like pointers to data members. So we've decided to ditch zero-initialization and go for value-initializing everything, pushing the "problem" of replacing a loop of value-initializations with a corresponding memset(0). I guess that the NeedsConstruction flag has not been updated; FWIW, it could be ditched entirely? All types are value initialized, whether it's in containers, in QVariants and so on. 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
[Development] QMetaType::NeedsConstruction vs QTypeInfo::isComplex
Hi, currently we promise that if for a type its QMetaType does not have the NeedsConstruction flag set, it can be initialized with memzero. We set that flag if the type is complex according to QTypeInfo. However, after the discussion in https://lists.qt-project.org/pipermail/development/2020-November/040546.html, primitive types are not complex, but only guarantee that they can be memcpyed not memzeroed. Therefore either the implementation or the documentation of NeedsConstruction needs to change (note that Qt itself does not use that flag anywhere as far as I can tell). But which of those two options should we choose? What are the actual use-cases of that flag anyway? -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] New features in CI
Hi all, While the CI maintenance break today took a little longer than usual, it also came with two very nice new features that will hopefully make everybody’s life easier. First of all, you can now find a ‘Precheck' button in gerrit. That button triggers a full CI test run of the Sha1 in the change and will post back the result of that run as a comment. This should make it a lot easier to test some of your changes before manual reviews start or at any other time when you need them. But please be aware that those runs do consume resources from the CI system, so you shouldn’t just hit that button for anything. Secondly, we have now added a new mode on how CI integrations work. So far all changes that got staged since the last CI run would be tested together. This had the downside that we would be testing a large amount of independent changes together in one CI run. If one of those changes had a problem, all changes would get rejected. Worse, many people would then simply hit the ‘Stage’ button once again assuming it wasn’t their change that caused the problem. You probably have all experienced this in some form or another. To fix this, we have now added a new feature (called parallel staging branches), where CI rounds are not serialised anymore. Instead, COIN will start a new CI run 15 minutes after a change (or a set of changes) got staged. It will start that run independently of whether another CI run is currently happening. If a staging branch passes, all the changes contained in that branch will be merged into the target branch (can be a fast-forward merge). If the merge produces a conflict, the staging branch will get rejected even if it passed CI. This means that COIN will usually only test changes that are being staged together. The advantages are that you can more easily pin down a change that caused a CI failure, and that your changes will not get rejected because a buggy change got staged in the same CI run (at least it’s a lot less likely). The one drawback is that we can in some rare cases end up with a repository in a state where two staging branches passed CI and didn’t conflict when merging them, but the merged state does not pass CI anymore for some reason. In that case the branch will be blocked until someone stages a fix for the problem. But we do expect this to happen rather seldom, so I do believe that the benefits far outweigh the drawback. For now this feature is only enabled in qtbase/dev, but if it works out well, we will most likely enable it for further repositories and branches. Last, but not least I’d like to thanks Toni Saario and Jukka Jokiniva for doing all the the hard work :) Enjoy! Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Monthly CI maintenance break - March (Mon 1st Mar 2021)
In case forgotten…this is ongoing. Should be over soon. -Olli From: Development on behalf of Ville-Pekka Karhu Date: Monday, 22. February 2021 at 15.58 To: Qt development mailing list Subject: [Development] Monthly CI maintenance break - March (Mon 1st Mar 2021) Hi all! We’ll have our scheduled maintenance break on next Monday (1st of Mar). We’ll begin our work at 6:00 UTC and you can prepare for 6 hours of CI not working. Br, VP ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Monthly CI maintenance break - March (Mon 1st Mar 2021)
Hi, Maintenance break is done. VP From: Ville-Pekka Karhu Sent: Monday, March 1, 2021 2:06 PM To: Qt development mailing list Subject: Re: Monthly CI maintenance break - March (Mon 1st Mar 2021) Hi, It seems that 6 hours was not enough, so maintenance break is still ongoing with no estimated time of completion. We will let you know when it is done. VP From: Ville-Pekka Karhu Sent: Monday, February 22, 2021 3:55 PM To: Qt development mailing list Subject: Monthly CI maintenance break - March (Mon 1st Mar 2021) Hi all! We’ll have our scheduled maintenance break on next Monday (1st of Mar). We’ll begin our work at 6:00 UTC and you can prepare for 6 hours of CI not working. Br, VP ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New features in CI
On Mon, Mar 01, 2021 at 01:25:50PM +, Lars Knoll wrote: First of all, you can now find a ‘Precheck' button in gerrit. That button triggers a full CI test run of the Sha1 in the change and will post back the result of that run as a comment. so this simply exposes the pre-existing functionality. that means that testing a change accurately requires always rebasing it, which is exactly the opposite of the usual recommendation to not rebase unless conflicts occur. the system should instead create a build branch which is simply a rebase of the chosen sha1 (incl. its ancestors) to the tip of the target branch. If a staging branch passes, all the changes contained in that branch will be merged into the target branch (can be a fast-forward merge). you mean actual git merges, rather than rebases/cherry-picks? that will lead to a completely insane history in busy repositories. The one drawback is that we can in some rare cases end up with a repository in a state where two staging branches passed CI and didn’t conflict when merging them, but the merged state does not pass CI anymore for some reason. if you accept that, there is no point in the custom CI gate in the first place - just assign a required review label to the CI system like almost every other project in the world does. also, rather than sinking more and more resources into coin, you should have a look at zuul, which is a very gerrit-centric CI with a much better feature set and an actual community around it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New features in CI
On Mon, Mar 01, 2021 at 01:25:50PM +, Lars Knoll wrote: >> First of all, you can now find a ‘Precheck' button in gerrit. That >> button triggers a full CI test run of the Sha1 in the change and will >> post back the result of that run as a comment. Oswald Buddenhagen (1 March 2021 17:02) replied: > so this simply exposes the pre-existing functionality. A bit better packaged than the internal form used to be, but yes. > that means that testing a change accurately requires always rebasing > it, which is exactly the opposite of the usual recommendation to not > rebase unless conflicts occur. the system should instead create a > build branch which is simply a rebase of the chosen sha1 (incl. its > ancestors) to the tip of the target branch. Given that Gerrit now keeps track of +1s and +2s when rebases are clean, the pain due to rebases is significantly reduced these days. It still fills up mail-boxes, of course, but the old recommendation is at least somewhat less critical than it used to be. And, as ever, do not let the craving for perfection be a reason against accepting an improvement. One advantage of testing the branch as it stands in Gerrit, rather than a rebase of it, is that line numbers in the resulting build report will really correspond to those in the commit tested, without random perturbations due to changes the branch was rebased onto. >> If a staging branch passes, all the changes contained in that branch >> will be merged into the target branch (can be a fast-forward merge). > > you mean actual git merges, rather than rebases/cherry-picks? that will > lead to a completely insane history in busy repositories. I'm a bit curious about that one myself; but it can perfectly well be implemented as a rebase, after all. >> The one drawback is that we can in some rare cases end up with a >> repository in a state where two staging branches passed CI and didn’t >> conflict when merging them, but the merged state does not pass CI >> anymore for some reason. > > if you accept that, there is no point in the custom CI gate in the first > place - just assign a required review label to the CI system like almost > every other project in the world does. You're taking for granted your earlier demand that the system be reworked to test a rebased version of the branch. Without that, there remains value in a separate CI gate. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New features in CI
On Mon, 1 Mar 2021 at 15:31, Lars Knoll wrote: > To fix this, we have now added a new feature (called parallel staging > branches), where CI rounds are not serialised anymore. Instead, COIN will > start a new CI run 15 minutes after a change (or a set of changes) got > staged. It will start that run independently of whether another CI run is > currently happening. If a staging branch passes, all the changes contained in > that branch will be merged into the target branch (can be a fast-forward > merge). If the merge produces a conflict, the staging branch will get > rejected even if it passed CI. > > This means that COIN will usually only test changes that are being staged > together. The advantages are that you can more easily pin down a change that > caused a CI failure, and that your changes will not get rejected because a > buggy change got staged in the same CI run (at least it’s a lot less likely). > > The one drawback is that we can in some rare cases end up with a repository > in a state where two staging branches passed CI and didn’t conflict when > merging them, but the merged state does not pass CI anymore for some reason. > > In that case the branch will be blocked until someone stages a fix for the > problem. But we do expect this to happen rather seldom, so I do believe that > the benefits far outweigh the drawback. > > For now this feature is only enabled in qtbase/dev, but if it works out well, > we will most likely enable it for further repositories and branches. Hallelujah. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New features in CI
On Mon, Mar 01, 2021 at 04:22:01PM +, Edward Welbourne wrote: One advantage of testing the branch as it stands in Gerrit, rather than a rebase of it, is that line numbers in the resulting build report will really correspond to those in the commit tested, without random perturbations due to changes the branch was rebased onto. that's true, but otoh the build branch contains real commits that can be viewed on gerrit itself. if somebody bothered to implement auto-linking (just steal the compiler output parsers from qt creator) that would be even easier to use (esp. for others than the owner) than accurate line numbers. Oswald Buddenhagen (1 March 2021 17:02) replied: you mean actual git merges, rather than rebases/cherry-picks? that will lead to a completely insane history in busy repositories. I'm a bit curious about that one myself; but it can perfectly well be implemented as a rebase, after all. yeah, but it occurs to me that post-integration rebases mess up the linking of sha1s to ci results. the system would have to rewrite the logs post-integration. if you accept that, there is no point in the custom CI gate in the first place - just assign a required review label to the CI system like almost every other project in the world does. You're taking for granted your earlier demand that the system be reworked to test a rebased version of the branch. no, but you are conflating two independent process parameters. it's perfectly possible to keep a separate manual trigger for the authoritative builds, which would trigger auto-integration upon success. the applied integration/merge strategy may still require a custom modification. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
