[Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)
bjoern.michaelsen at canonical.com
Thu Oct 6 01:58:30 PDT 2011
Hi Tor, all,
On Thu, 6 Oct 2011 09:01:06 +0300
Tor Lillqvist <tml at iki.fi> wrote:
> Seriously, is it really that awful if a few tinderboxes are red for
> some days?
Yes, it is. Reasons follow below.
> Some of them are red for weeks.
IMHO we should do something about that too.
> Is just bluntly reverting the right way to solve problems? If it is,
> will have to remember that.
At least for "breaks all platforms, cant possibly be right"-commits it
is. If that happens the commiter/pusher did not do his due diligence
and shouldnt complain. As a rule of thumb I personally expect every
push to be tested on one platform at least(*). If it obviously was not,
I have no qualms against a revert -- actually I would expect others to
do the same (unfortunately some commits can even be fixed by that
because of interdependencies with other changes).
Reasons why tinderboxes red for a week are bad:
- Whatever we had in people trying their first build this week are gone
and will likely never come back.
- It makes certain work almost impossible. I asked Fridrich about
testing feature/kill-set_soenv on cygwin, but that has to wait until
the one commit in the month where the windoze tinderbox is green
- We do not get any early warnings by people testing nightlys as there
- While the tinderboxes are red for sustained periods of time, we are
flying blind. Commits breaking things additionally in interesting
new ways sneaks in and pile up shadowed by the first breaker.
- Sustained "tinderbox is red"-periods are blackboxes for "git bisect".
- There is a moral hazard: When you get twenty tinderbox breaker mails a
day you just ignore them (or procmail them with the same result).
Also newcomers (without procmail rules) who finally got their first
commit in are scared away from the project, because these mails are
telling them they either got it wrong (which is what a first commiter
would suspect) or others around him are careless are not encouraging
- A break on master causes lots of duplication of work as many people
are working on a fix and once they push their fixes likely conflict
and cause even more trouble. The most recent example is almost poetry:
A commit pushes an unbalanced ifdef in scp2:
this of course breaks the build for everyone. Lots of people get hit
by it and start debugging and searching for the problem -- among them
Caolan and I. Caolan pushes his fix first:
I too fix the issue (as I pulled two commits before Caolans fix), test
it and pull -r/push it back:
Note that the rebase silently resolved the conflict: "Remove one
#endif? Roger, Wilco."
Now two #endifs got removed and master is broken _again_ until:
which also collided midair _again_ with the same fix from Fridrich
(which he had to throw away, because I was faster this time).
As result master was broken for half a day, lots of useless
communication on IRC about it and lots of wasted resources.
Now this might seem like a rare example but it likely isnt:
- A lot of fixes can be mutually exclusive and still apply be without
conflict -- it does not need the poetry of applying the exact same fix
twice for that.
- Even if the fixes collide on rebase, the additional work and wasted
time is already gone.
With a project this size and these numbers of commits this is bound
to happen again and again rather sooner than later. This ain't Kansas
I dont want to single anyone out here, this can (and will, given
some time) happen to anyone with our current setup. But please, please
be aware of the consequences until we have a better one.
Finally: This is a prime selling point why gerrit with tinderboxes
testing commits _before_ they hit master is a Good Thing(tm), but I
think this point is painfully obvious now, isnt it?
(*) Do I do that for a those mythological "cant possibly break
anything"-commit right now? No, not a build from scratch for every one
of them as chances are good that somebody else pushes while I build and
I would need to rebase again anyway. But if I botch such a commit I
expect the exact blunt reversal you talk about if I am to slow to react
in fixing it myself. My little broken commit can possibly be more
important than the health of master for everyone.
More information about the LibreOffice