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