Re: 'make test' fails in pu

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Sometimes a breakage in pu is surprising (e.g., it breaks only on a
> platform that the maintainer does not run "make test" on) and we would
> want to know about it. But sometimes it is merely that there is a
> work-in-progress. And it probably requires a human to tell the
> difference.
>
> So no, I do not think automatically mailing on test failures in pu is a
> good idea. Manually peeking at them and sending fixes before the series
> is merged to next _is_ very much encouraged, though. :)

Thanks, that is exactly what people saw.  From time to time, I queue
a topic that does not pass the tests on 'pu', hoping that somebody
sufficiently interested would step in to collaborate with the author
of the topic to move things forward when the breakage looks simple
enough, and sometimes that original author happens to be me.

This case, it turns out that the breakage is not so simple, though.
Inside the rename detection logic, I want to peek the rename source
array to decide which deletion filepair to keep, but rename source
array itself has pointers to the original filepairs the loop wants
to free, so the WIP code was peeking into a freed piece memory X-<.

> Unlike "pu", "next" and "master" should never fail tests (I think that
> Junio will not push them out if the tests have failed on his system). So
> failures there are much more likely to be interesting platform bugs (but
> of course, testing "pu" is still encouraged, as we may catch problems).

True.  I do not mind automated tests on 'next', and testing 'pu' and
helping the topic to move forward is very much encouraged, but
sending test results on 'pu' blindly is often more noise than it is
worth.