Approximating a missing platform with gerrit

Stephan Bergmann sbergman at redhat.com
Thu Jul 16 00:26:35 PDT 2015


Our gerrit/jenkins setup is fine in detecting change requests that would 
break the build.  But when you try to (mis-)use it to modify a change 
request until it passes on all platforms (because you don't have direct 
access to one of the platforms, say), the situation is not that ideal. 
As I recently experienced when I tried to get 
<https://gerrit.libreoffice.org/#/c/16880/> "Make content of OSL_ASSERT, 
DBG_ASSERT, etc. visiblie in non-debug builds" to build on Windows---and 
ultimately resorted to a local Windows build anyway, to speed things up.

I do understand that this may be issues in the design of the setup that 
are hard to overcome, but wanted to dump this food for thought anyway:

* Once two of the three platforms are known to compile a give change 
fine, it would be nice if one could requests builds of new versions of 
the change for only one specific platform (esp. when then newly made 
modifications are in platform-specific code, so should not affect the 
already-good platforms anyway).  Could save time and reduce (real-world) 
waste.

* Sometimes, a build fails for spurious reasons midway through, and you 
need to start another build.  But the only way to re-trigger a build is 
to rebase the change.  (The downsides are: disrupts the history of the 
change's revisions; the rebased-upon master revision itself may be 
broken; and there just might not be a new master revision to rebase 
against yet at all)  It would be nice if one could force rebuilds of 
already built change request vesions.  (In my example, this happend at 
patch sets 6 -> 7.)

* In cases like in my example, where the change breaks platform-specific 
code in various places in the code base, it can be tedious and wasteful 
to find all those places incrementally, one place per new build.  It 
would be nice if one could trigger builds that employ "make -k".


More information about the LibreOffice mailing list