bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

On Wed, 30 Aug 2023 at 12:39, "Dr. Arne Babenhauserheide" <arne_bab@web.de> wrote:

> Please don’t remove packages that are broken on the CI. I often had a
> case where no substitute was available but the package built just fine
> locally. This is not a perfect situation (nicer would be to track why it
> doesn’t come from CI — sometimes it’s just a resource problem on the
> CI), but if you removed a package I use that would break all updates for
> me.

Well, I do not think that any policy will mark a package for removal on
the first build failure.  However, if the same package is still failing
after several X <duration> or attempts, it means something is wrong.
Marking it as a candidate for removal implies:

 1. check if the failure is from CI when it builds locally,
 2. keep a set of packages that we know they are installable.

For instance, ocaml4.07-* packages are failing since more or less April.

https://data.guix.gnu.org/repository/1/branch/master/package/ocaml4.07-ppxlib/output-history

Does it make sense to keep them?  For another example, some perl6-*
packages are failing since… 2021.

https://data.guix.gnu.org/repository/1/branch/master/package/perl6-xml-writer/output-history

Does it make sense to keep them?

The usual situation is that CI is able to build the packages.  The set
of packages that CI is not able to build is very limited and it is the
exception.

Having a rule to deal with the regular broken packages appears to me a
good thing and very helpful to keep Guix reliable.  And that rule cannot
be based on rare exceptional cases.


> If a change in packages breaks my manifest, that is extremely painful.

Yeah, and such rule for dealing with broken packages will be helpful for
detecting such change and so avoid such situation.

Cheers,
simon