Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Thu, Oct 6, 2011 at 1:01 AM, Tor Lillqvist <tml@iki.fi> wrote:
because  oox/source/drawingml/customshapepresets.cxx, a 4MB source,
made gcc blow-up both on Mac and on Gentoo....

The horror! The horror!

Seriously, is it really that awful if a few tinderboxes are red for
some days?

That particular one get  Linux and Mac to die due to a gcc abend...it
is not like it is missing an include of some strategically placed
#ifdef

Some of them are red for weeks.

And that is very  bad... hopefully with mingw the tinderbox iteration
time will be in part with other platform and in the 15-20 minutes
range.
the current windows tinderbox itarate at best in 10 hours or so. it
makes it completely unpractical  to monitor's one's commit and to
identify which commit is responsible of a breakage.


Is just bluntly reverting
the right way to solve problems? If it is, will have to remember that.
that particular revert was not 'blunt'. that particular commit did not
just make the build failed, it made the box that tried to build fail
or at least suffer badly.
on Mac, thanks to the fact that gcc ran as a 32 bit process it died
before doing much damage to the rest of the system. on my linux, it
was happily consuming 7+GB of memory by the time I manually kicked
it...a commit that break the build is one thing, one that essentially
DOS the tinderboxes are another.

Many times, whenever I can, I try to fix the problematic commit rather
than reverting.
and the work is not lost... it is right there in git. if you find of a
way to make it work, please, by all means do so.

but to answer your more general question: yes red tinderboxes are bad, very bad.
because it has a run-away effect:
When master is broken, you can't check your work properly, so you
increase the odd of yourself pushing a broken commit leading to an
even more broken master;
In the mean time tinderbox are not able to produce daily build...
which means that QA cannot do their part to find bug early.
Yep it is that bad on windows... and yeah we haven't been able to
produce a daily build for it in weeks... but that is no reason to make
that the 'standard'.

Norbert

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.