Bruno Haible via Bug reports for the GNU Internet utilities <bug-inetutils@gnu.org> 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
Description: PGP signature
