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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> I recommend this `git commit` flag in these cases:
>>
>>     -n, --[no-]verify
>>         By default, the pre-commit and commit-msg hooks are run. When
>>         any of --no-verify or -n is given, these are bypassed. See also
>>         githooks(5).
>
> Yes, but it's a nuisance to have a commit fail, and then to try to
> recollect or find in the docs the exact name of this option.  (I use
> it so infrequently that I succeed to never remember its exact
> spelling.)  It makes what should have been a very short action take
> several tens of seconds.
>
>> For my part, I think git commit hooks are quite useful to avoid obvious
>> mistakes such as trailing whitespace, and I think if we disabled them
>> we'd see more of that.
>
> When they don't produce false positives, sure.

Fully agreed, on both counts.

>> I think we should recommend always running the full test suite on every
>> commit before pushing
>
> I think this is impractical: the time needed to run the suite is too
> long, even on a fast machine.  In any case, let's start by achieving
> the smaller goal of having the test(s) for the file(s) being changed
> in a changeset be always run.  Experience shows that this is not
> always the case.

Maybe impractical, yes.  But I'm only suggesting it as a recommendation,
not as a heavy-handed rule where we will bring down the hammer if it's
not followed.  In practice, I'm hoping a strong recommendation would
just lead to the test suite being run more often.

I like the idea of running the test for the relevant files.  However, we
should also highlight that changing one file can sometimes make tests
fail in the tests for another.

>> To make that more realistic, `make check` has to be both useful and
>> fast.  I think it's getting more and more useful over time (this part
>> takes real work), but it doesn't have to be too hard to also make it
>> faster.  For example, I've argued in the past that we should be
>> proactive with moving slow tests to :expensive, where "slow" is any
>> individual test case that takes more than one second to run or so.
>
> I think almost all (if not all) the tests run by default are already
> fast enough.  But all of them added together take a significant amount
> of time.  And we add tests all the time (and will continue to do so,
> since our test coverage is still far from satisfactory).

I didn't look recently, to be honest, so I can't say much to that.
I just know that when I did look, I found some slow tests.

If that's not true now, all the better.