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

[Pip Cet]

"Stefan Kangas" <stefankangas@gmail.com> writes:

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

I think if we add a new make target with the idea that you run it prior
to a push, we can then decide what precisely would be good for it to do
without having to rescind or amend our previously-issued advice.

My suggestion is "make push", which would not run "git push" but should
probably include instructions to do that, if and only if the checks
succeeded.  ("prepush" might be the more obvious name, no reason not to
have both).

For example, "make (pre)push" should probably fail if compiling a test
causes a warning; this is currently true due to bug#75633.

But I don't know how to do that, so how about (this uses make check, not
make check-all):

diff --git a/Makefile.in b/Makefile.in
index 342bec11d81..3b624bde60e 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1138,6 +1138,9 @@ $(CHECK_TARGETS):
 test/%:
        $(MAKE) -C test $*
 
+prepush: check-info check
+
+push: prepush
 
 dist:
        cd ${srcdir}; ./make-dist
@@ -1153,7 +1156,7 @@ $(DOCS):
        $(MAKE) -C doc/$(subst -, ,$@)
 
 .PHONY: $(DOCS) docs pdf ps
-.PHONY: info dvi dist html info-dir check-info
+.PHONY: info dvi dist html info-dir check-info push prepush
 
 ## TODO add etc/refcards.
 docs: $(DOCS)
@@ -1252,7 +1255,7 @@ uninstall-ps:
 check-info: info
        cd info ; \
        bad= ; \
-       for file in *; do \
+       for file in *.info; do \
          test -f "$${file}" || continue ; \
          case $${file} in \
            *-[0-9]*|COPYING|dir) continue ;; \

(I discovered the "check-info" target while writing this, but that's
precisely what I'm talking about.)

> proactive with moving slow tests to :expensive, where "slow" is any
> individual test case that takes more than one second to run or so.

If we automate this and keep the auto-generated metadata out of the .el
files, what are the objections?  If it then turns out we don't need the
manual :expensive tag at all anymore, we can drop it.

Pip