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

[Stefan Kangas]

Pip Cet <pipcet@protonmail.com> writes:

>> So while I applaud the effort of Pip Cet to automate away boring minutia
>> such as this one, perhaps we should bring these ideas to the texinfo
>> developers?
>
> Now reported as a bug, let's see what happens.

Great!

> I did not mean git hooks.  Git *commit* hooks are already over-used by
> Emacs, and I'm not sure they're useful enough to be set up
> automatically, without my explicit consent, whenever I run autogen.sh.
>
> I'm not saying git hooks are entirely useless, but commit hooks in
> particular feel like an unwarranted intrusion into my workflow.  I often
> want to mark a temporary commit with DO NOT COMMIT, but that makes the
> first line longer than some hook thinks it should be.

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).

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.  So given that they can be disabled
situationally, I think they are ultimately worth it.

>> We could have something that one could install and use optionally, but
>> even then I'd request it to be very fast, so that the whole thing takes
>> less than a fraction of a second to run.  Much more than that, and I'd
>> probably just turn it off again.
>
> I hope "make check" can be fixed, but right now it is that way for me.
> It's still incredibly useful, but running it on an enable-checking build
> without optimization requires some patience (it just did find a bug in
> one of my patches, though).
>
> And if the idea is to do the best we can in the limited time period
> until the user confirms they do want to push (this is my idea of
> zero-cost checking), always running the tramp tests first seems
> suboptimal.  A good randomization strategy would be important; running a
> full test matrix on every commit isn't viable.

I think we should recommend always running the full test suite on every
commit before pushing, at least until we can get something closer to a
proper CI pipeline in place.  New warnings and failing tests are far,
far too commonly introduced as is, and it's a real pain to have to
constantly bisect to find the offender.

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.

>> (In projects at $WORK, we run an incredibly fast linter on every commit
>> that finishes within in a couple of milliseconds.  It is very nice.)
>
> I think it would be even better to start a background test which tries
> to find problems as efficiently as possible in however much time you
> give it, starting with the quickest tests (that's data we have; a better
> prediction of the likelihood of failure would be hard) and only runnnig
> the analyzer build if the user falls asleep.

Interesting idea.  I've never seen anything like that.