Re: planning for beta-testing gnulib-tool.py

[Simon Josefsson]

Bruno Haible <bruno@clisp.org> writes:

> 5) Possibly it makes also sense to allow GNULIB_TOOL_IMPL to be set to
>    'sh+py'. In this case the script will make a full copy of the destination
>    dir, run the shell implementation and the Python implementation on the
>    two destination dirs, separately, and compare the results (again, both
>    in terms of effects on the file system, as well as standard output).
>    And err out if they are different.

Generally I'm happy to hear about speedupds of gnulib-tool!  The plan
sounds fine.  I think this step 5) is an important part to get
maintainers try the new implementation, and report failures that needs
to be looked into.  If there was a small recipe I can follow to get a
diff that can be reported back, I would run it for a bunch of projects
that I contribute to.

While a self-test suite for gnulib-tool would be nice, some real
regression testing by attempting to build a bunch of real-world projects
that rely on gnulib-tool may be simpler to realize.  If there is a CI/CD
that builds ~30 different real-world projects (perhaps at known-good
commits) and compares the output against an earlier known-good build,
for each modification to gnulib-tool in gnulib, that would give good
confidence to any change to gnulib-tool.

/Simon

signature.asc
Description: PGP signature