Re: CI setup

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Sat, 02 Aug 2025 20:20:45 +0200

Newsgroups	gmane.comp.gnu.inetutils.bugs
Message-ID	<[email protected]>

Bruno Haible via Bug reports for the GNU Internet utilities
<[email protected]> writes:

>> - My primary use of CI is to have confidence in the tarball I release,
>>   thus it is important to widely test the actual gnulib commit used for
>>   the release on many platforms.
>
> That is, well, an "occasional" build, not a "continuous" build. One of
> my packages (libffcall) uses an occasional build, and just yesterday I had
> to fix a regression that I made 11 months ago. It costs me more time
> to fix a bug after 11 months than after at most one week: the time to
> re-think about the old patches that are not present in memory any more.
>
> The advantage of a "continuous" build is also that any new maintainer can
> make a new release in relatively short time, because release show-stoppers
> have not had time to accumulate.

My view is changing towards seeing gnulib like just any other build-time
dependency.  We are using versioned build dependencies of
Trisquel/Guix/Debian/RHEL and autoconf, automake, help2man, etc in CI/CD
because we want to test those versions.  We aren't using bleeding edge
autoconf, automake, etc in CI/CD when building inetutils.  So using a
specific gnulib commit seems to match how we treat all other build
dependencies.

However I do agree with you about the utility of ALSO building inetutils
with bleeding edge gnulib.  Even using bleeding edge Debian testing
helps to catch similar issues.  Using bleeding edge autoconf, automake
etc would probably help too, although it is serious work to keep such a
complex CI happy all the time.  So yes, I think we need building of both
bleeding edge dependencies AND some known set of released old and stable
build dependencies that we still support.

/Simon

signature.asc (application/pgp-signature, 1.2 KB)