Re: CI failure

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Sat, 02 Aug 2025 13:08:55 +0200
Newsgroups	gmane.comp.gnu.inetutils.bugs
Message-ID	<[email protected]>
Thanks for the report, I have merged the pull request to fix this now.

I had several mixed reactions to this, and had to reflect a bit and some
of my (still unfinished) thoughts are:

On CI using latest gnulib

- 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.  Thus, changing all of CI to use latest
  gnulib seems like a bad idea for me.

- I realize that testing inetutils with latest gnulib in CI is useful to
  catch gnulib-related (reverse) regressions.  I admit this somewhat
  reluctantly, because to have good coverage this means almost a
  doubling of CI jobs: for each OS, you would want to build with both
  latest and the GNULIB_REVISION pinned gnulib.  That is a lot of
  energy/CPU usage.  Still, I think it is okay situation to have at
  least one CI job on some stable platform (say Trisquel 12 which is
  derived from Ubuntu 22.04) that builds inetutils with latest gnulib.
  Right now your github CI performs this tasks, but I haven't managed to
  get into the habit of looking at it just yet, so I'll see about adding
  one such job to the gitlab CI too so I will notice it quicker.

Where to report bugs:

- I'm not sure it is feasible to reach for perfect consistency on this
  without sacrificing end-user convenience to report bugs.  A simple
  solution is to say that only [email protected] is valid.  However
  there are some people who may refer codeberg or savannah, or even the
  gitlab page we have here: https://gitlab.com/gsasl/inetutils/

  Other places to report bugs are to the Debian and other OS'es bug
  trackers, and I think it is nice for us to monitor them too.

  I thought about closing down issue tracker on some subset of these
  platforms, but I couldn't find convincing arguments one way or the
  other.  So another point of view is to actually allow several
  mechanisms, for as long as there is someone monitoring each way to
  report bugs.  This may fragment resources, and could lead to user
  annoyance when they have to escalate on another channel to get
  attention.

  So I'd prefer to say that [email protected] and
  savannah/codeberg/gitlab issue trackers are all fine way to reach us,
  and that merge requests on codeberg/gitlab are fine too.  We could
  setup notifications to [email protected] on platform actions, but
  I find those e-mails really ugly and they tend to destroy the mailing
  list feeling.

What do you think?

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