Re: master e54b94c28cd: Use @xref more consistently; "See @ref" -> "@xref"

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 27 Jan 2025 08:41:24 -0600
> Cc: pipcet@protonmail.com, luangruo@yahoo.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I've just run the test suite with "make check", and I can say that
> > only tramp-tests is relatively slow (about 1 min: 59 tests, each one
> > about 1 sec).  The rest are very fast, but running the suite still
> > takes 13 min on a not-so-fast machine.  That's a long time to run
> > after each commit.
> 
> Yeah, that's a long time.  Maybe you're right, and we should not
> recommend running it for every commit.  (FWIW, I do try to do it here,
> as it only takes around 70 seconds on this machine.)

What I think would be good is to have some kind of data structure
mapping a source file to the tests which exercise some of the code in
that source file.  The first approximation is to run FOO-tests when
you modify a file FOO, but some FOO's get used in many places in the
test suite, so this is not a simple 1:1 relation.  Then we could at
least ask contributors to run the relevant tests as part of the
submission process.

> Taking a step back, I think the real solution is to have some sort of CI
> system in place that automatically notifies contributors when one of
> their commits cause a new warning or a failing test.  We have EMBA,
> which is good and useful, but I don't think most people look at that, so
> it still takes manual work on behalf of a few people to make people
> aware of new test failures.

Having EMBA or something similar email the guilty parties in case of
failures would be great, indeed.

> Ideally, we would have something in-band, i.e. an automated email, so
> that we could avoid this manual work.  It would probably be more
> effective, too.  I would be interested to know if there are any
> pre-existing tools that we could use.  It might also be worth
> considering building a custom one.  Maybe we should add looking into
> something like that to etc/TODO?

It cannot do any harm.  But I envision a problem with setting this up
because the gnu.org infrastructure mighty not be up to the additional
load.  However, we don't need to be afraid of this before someone
actually works on setting this up.