Approximating a missing platform with gerrit

[Ashod Nakashian]

One way to do this is to make gerrit build broken platforms until all pass,
then, when all pass but not the same commit hash, it rebuilds the ones
behind. So in the end they would all have been built on the latest (in case
something broke in the interim).

In this "build failed platforms only" mode, `make -k` could be utilized.

The above should solve all the issues you raised and doesn't require manual
intervention (which is error prone and potentially tedious).
Now for volunteers who know their way around gerrit/jenkins.

On Thu, Jul 16, 2015 at 3:26 AM, Stephan Bergmann <sbergman at redhat.com>
wrote:

> 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".
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150716/b3156fd1/attachment.html>