Yes, and I'll probably do that. But in my experience, this has a very high probability of burying the problem, i.e. the incentive for actually fixing the problem is reduced dramatically. It's better to do test-breaking things on separate branches when possible. IMO expected failures are for when a feature is being designed and still incomplete, not when it was already working.

João

On Mon, Jun 18, 2018, 16:18 Eli Zaretskii <eliz@gnu.org> wrote:

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 18 Jun 2018 14:24:39 +0100
> Cc: Glenn Morris <rgm@gnu.org>, Emacs developers <emacs-devel@gnu.org>,
> Tino Calancha <tino.calancha@gmail.com>
>
> > Yes. But it is the master branch, where not everything can be expected
> > to work all the time. I think the main thing is, we're _going_ to fix
> > this bug.
>
> Well, I respectfully and totally disagree. The reason we have automated
> tests in Hydra is to catch unintentional breakage, not intentional
> breakage. And, IIUC that test is the only one preventing a successful
> "make check".

Isn't there a way to mark a test as expected to fail?