Re: Test runs timing out on b5

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 15 Jan 2017 13:41:01 +0200
    From:        Andreas Gustafsson <gson%gson.org@localhost>
    Message-ID:  <22651.24525.719962.508830%guava.gson.org@localhost>

  | security(7) says "Upon detection of a buffer overrun, SSP will
  | immediately abort execution of the program and send a log message
  | to syslog(3)."

OK, I am currently doing a full build so I can test this (I've been away,
and my test system was rather stale...)   That gives a better clue where to
look (if Christos doesn't fix it before I get the opportunity to debug).

  | The tests of 2017.01.12.00.38.01 sources yielded "new failures: 19
  | test cases" rather than "did not complete" because I increased the
  | timeout before that test was run.

Yes, figured that out just after sending the first message...

  | CPU time is cheap, and I think there is value in being able to say
  | that you have actually tested the sources immediately before and after
  | a suspect commit, rather than relying on the assumption that certain
  | types of commits can't possibly cause problems.

I guess ... when I first was thinking of this issue I was considering
more what should trigger a normal build cycle to start - clearly there's
no point if there have been no commits since the last build... I was thinking
that perhaps we could save some resources (more tests seem to fail when b5
is busy doing lots of parallel compiles and tests it seems) by not starting
a build if the only changes are ones that are very unlikely to cause
problems (almost any doc commit would count).   After a commit to a .c .h .sh
or build system file (Makefiles, anything.mk, set lists, ...) then start
the next build cycle (which will also test any earlier doc, etc, changes of
course, just in case a *roff error or something causes a failure).  If all
works, great, if it fails, then it could do the same as now and attempt to
find the cause by dividing the commits.

kre