[Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)

[Bjoern Michaelsen]

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
  again.
- We do not get any early warnings by people testing nightlys as there
  are none.
- 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
  at all. 
- 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:

http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=5bd2890a56125d391b42f34d51e2e0c57b0a80b0

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:

http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=a2623000c16d9f02bb945559a91d5bd76651772a

I too fix the issue (as I pulled two commits before Caolans fix), test
it and pull -r/push it back:

http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=d2f633c5464fd4339e9e804c97596a78bfa58e62

Note that the rebase silently resolved the conflict: "Remove one
#endif? Roger, Wilco."
Now two #endifs got removed and master is broken _again_ until:

http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=e944e135bc157d092532fff0829390fa7d4fa958

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
anymore, Toto.

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?

</rant>

Best,

Bjoern

(*) 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.

-- 
https://launchpad.net/~bjoern-michaelsen