Re: Gerrit: Reliability and fidelity of verification results
On Tue, Jul 21, 2015 at 2:40 PM, David Ostrovsky d.ostrov...@gmx.de wrote: and all these with release|debug permutations. Quite a lot resources, but we don't care, we should have enough resources for now, right? No, not even close. fyi: last 7 days we did 271 gerrit build, so 813 build we also did 717 tinderbox build. or about 218 build a day... (that is counting only the build under jenkins) There are tinderbox for dgb/rel of linux/mac and windows + one debug on win64 the gerrit build only do mac+linux+win on release mode and no I do not have enough resource to do more yet. As resource come online, I will try to get gerrit to switch to make check dbgutil mode instead of release If I have enough I'll add gerrit-release for platform for witch I have excess bandwidth... that is if and only if make check is reliable for each platforms. Right now the limiting factor is windows.. but I should he 2 more beefy builder soon for windows. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
On Tue, Jul 21, 2015 at 1:54 AM, David Ostrovsky d.ostrov...@gmx.de wrote: On Mon, 2015-07-13 at 16:51 -0500, Norbert Thiebaud wrote: On Mon, Jul 13, 2015 at 1:51 PM, David Ostrovsky d.ostrov...@gmx.de wrote: And your patch 8 would have failed the same way on tb58/tb59/tb60 [...] The release builder have the so-called 'stale' tool chain. Just like in real-life and like other platform there is a diversity of platform and we usually do not drop support for 'older' platform unless there is an imperative motivation. I have another discrepancy with verification: [1]. This time tinderbox TB63 compiler version is ahead of mine: [2] TB63: GCC 4.8.3 Mine: GCC 4.8.1 On patch set 8 of this change, it's issuing -Werror=return-type: [3] even though the last statement is assert(false); The last statement is (void) (which is what assert resolve to in non debug build... hence the -Werror=return-type The run you pointed too was not a debug one: ... export ENABLE_DEBUG= ... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
Hi, On Mon, Jul 13, 2015 at 04:51:01PM -0500, Norbert Thiebaud wrote: Do not get me wrong. I applaud the effort to get rid of boost if we can.. that is a big and expensive dep. Except that I doubt we'll ever be able to do that. boost is used not only by libreoffice, but also by many bundled libs. And there is a lot of it used that'll hardly ever have an equivalent in the std. library. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
On Tue, Jul 14, 2015 at 3:49 AM, David Tardon dtar...@redhat.com wrote: Hi, On Mon, Jul 13, 2015 at 04:51:01PM -0500, Norbert Thiebaud wrote: Do not get me wrong. I applaud the effort to get rid of boost if we can.. that is a big and expensive dep. Except that I doubt we'll ever be able to do that. boost is used not only by libreoffice, but also by many bundled libs. And there is a lot of it used that'll hardly ever have an equivalent in the std. library. Then that make the notion of dropping maverick only to be able to go from boost::bind to std:: even less appealing. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
On Mon, Jul 13, 2015 at 1:22 AM, David Ostrovsky d.ostrov...@gmx.de wrote: I'd like to rise a question about reliability and fidelity of Jenkins Gerrit change verification results. Consider this change: 16877. It is so much easier to blame the tools indeed. * On patch set 8: [1] TB 66 voted VRFY+1 [2]. * On patch set 9: [3] TB 60 voted VRFY1-1 [4]. There weren't any changes in the affected file textdoc.cxx between those two patch sets. that is a bold thing to say when a patch change stuff like uno headers or rtl headers Moreover, while I don't have access to Mac OS X, I verified that the patch set 9 works as expected on Linux, with most recent clang version available. MacOSX rarely use the 'most recent clang version available' tb66 is Yosemite Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 tb60 is Maverick Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 And your patch 8 would have failed the same way on tb58/tb59/tb60 Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
On Mon, 2015-07-13 at 06:29 -0500, Norbert Thiebaud wrote: On Mon, Jul 13, 2015 at 1:22 AM, David Ostrovsky d.ostrov...@gmx.de wrote: There weren't any changes in the affected file textdoc.cxx between those two patch sets. that is a bold thing to say when a patch change stuff like uno headers or rtl headers I see how uno and rtl headers changes look suspicious, but the removal of get_pointer() function there is completely unrelated. tb66 is Yosemite Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 tb60 is Maverick Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 This is a known compiler bug; now with access to Mavericks: $ clang++ --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 and with this reproducer: [1] it's failing in the same way as on TB 60: __functional_03:43:11: note: candidate function not viable: 'this' argument has type 'const std::__1::__mem_fnint foo::*', but method is not marked const operator() (_A0 __a0) To rectify it: 1. Upgrade Mavericks to Yosemite 2. Upgrade Xcode to Xcode 6.3.2 (Build version 6D2105) $ clang++ --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 And now it works: $ clang++ -Wno-c++11-extensions mem_fn_const_problem.cxx ./a.out 42 Before new Xcode activation this diff shows the culprit: $ diff /Applications/.prepare-Xcode.app/reloc/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional 1224c1224 operator() (_ArgTypes... __args) const --- operator() (_ArgTypes... __args) And your patch 8 would have failed the same way on tb58/tb59/tb60 It requires a lot of efforts and time to upgrade all TBs to the newest baseline: 18 min. for OS + 22 min. for XCode. And we don't have time to do that. I understand all that. But what is the value of having conflicting tool chain versions verifying the Gerrit changes? So that change owners couldn't really trust the verification results, or if they do and submit changes that were approved by TB with up-to-date tool chain, they jeopardize green master or even stable release branch, because the same change is identified as breakage by a TB with stale tool chain? My suggestion is either to downgrade TB66 or upgrade all other Mac OS X TBs to the same baseline. [1] http://paste.openstack.org/show/371884 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
Norbert Thiebaud wrote: Do not get me wrong. I applaud the effort to get rid of boost if we can.. that is a big and expensive dep. There's some amount of irony here, in that for c++11 and beyond, it's sometimes just stuff moved out of boost into std, that makes our boost exposure seemingly shrink. ;) Cheers, -- Thorsten signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
On Mon, Jul 13, 2015 at 6:50 PM, Thorsten Behrens t...@documentfoundation.org wrote: Norbert Thiebaud wrote: Do not get me wrong. I applaud the effort to get rid of boost if we can.. that is a big and expensive dep. There's some amount of irony here, in that for c++11 and beyond, it's sometimes just stuff moved out of boost into std, that makes our boost exposure seemingly shrink. ;) Yes, but we already pay the price of std:: :-) and in the end not having to unpack few dozen of MB of headers would be a net win on my box make on boost is 1m6 elapsed and 500MB or I/O Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gerrit: Reliability and fidelity of verification results
On Mon, Jul 13, 2015 at 1:51 PM, David Ostrovsky d.ostrov...@gmx.de wrote: And your patch 8 would have failed the same way on tb58/tb59/tb60 It requires a lot of efforts and time to upgrade all TBs to the newest baseline: 18 min. for OS + 22 min. for XCode. And we don't have time to do that. I understand all that. Passive aggressive tone aside, for the record Yosemite + XCode download is 7-8G... In the best of time that is 2-3 hours of download here... But what is the value of having conflicting tool chain versions verifying the Gerrit changes? So that change owners couldn't really trust the verification results, or if they do and submit changes that were approved by TB with up-to-date tool chain, they jeopardize green master or even stable release branch, because the same change is identified as breakage by a TB with stale tool chain? The release builder have the so-called 'stale' tool chain. Just like in real-life and like other platform there is a diversity of platform and we usually do not drop support for 'older' platform unless there is an imperative motivation. Downgrading on Mac is not as trivial as you make it sound.. in fact please explain to me how to do that We've just put a brand new MacPro with Yosemite online, how would I go about 'downgrading' it to maverick ? Upgrading is 'easier' but not free.. and certainly not the 40 minutes you say, otoh at some point we will upgrade... But in the end your patch made a wrong assumption: There is no reason to use boost::bind when modern C++11 toolchain is supported. Apparently that support is not good enough for the supported baselines. Do not get me wrong. I applaud the effort to get rid of boost if we can.. that is a big and expensive dep. My suggestion is either to downgrade TB66 or upgrade all other Mac OS X TBs to the same baseline. My suggestion is: adapt your patch to avoid the issue. and/or bring the issue to the ESC. if dropping 10.9 is something that people things is worth doing... I surely can upgrade my 10.9 mac... although ti will take much more than 40 minutes to do so. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
