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

[Dr. Arne Babenhauserheide]

Hi,


I’m skipping a lot to get only to the most important points (save time
for us all).

Simon Tournier <zimon.toutoune@gmail.com> writes:
> Instead, it is QA that builds “pre-commit“ (patches).  Thanks to
> tireless Chris’s work since years, we have some tools for monitoring the
> impact of one change on the whole package set.  Somehow, if I have
> correctly understood, QA uses the Build Coordinator to list all the
> derivations and then build all the new ones generated by the change.
>
> So the answer to your question is yes. :-) Aside, help is welcome for
> improving QA.

So something was missing there that let the change to the ocaml package
slip through this january. This should have raised red flags somewhere.

Do we have documentation on the process? (link?)

>> Since a manifest is strictly dependent on all packages defined in it,
>> removing a single referenced package means that the manifest is broken:
>> no update works anymore. No security updates come in anymore — even if
>> the package in question worked locally. This is a situation we should
>> not cause.
…
> What I am proposing is: if the same package is still failing after
> several X <duration> or attempts, then we mark it as ‘broken’ and it
> becomes a candidate for a removal.  People who care raise their hand.
> And we have a better idea about the real status.

This means with the current functionality that the manifest is broken at
that point. Nothing can be updated anymore. I’ve been in that situation
a few times already with broken packages and it caused weeks of not
being able to update because I didn’t have the time to investigate.

That’s why I wrote the following:

> If we had a way to have placeholder packages (similar to the renamings)
> that emit warnings for missing packages but do not break the build, that
> would reduce the damage done by removing a package. But I think such a
> mechanism must be in place and tested before adding a rule to remove
> packages.

This would cause us to collect a slowly growing list of removed packages
that will be ignored (except for the warning) in manifests.

That way we would avoid breaking the setup when removing a package.


(define-public-removed the-package-variable
  (removed-package
    (name "the-package-name")
    (reason-for-removal "upstream stopped working a decade ago")))


The key difference between your scenario "some package is broken and I
cannot install it" and my scenario "I have a package in my manifest that
gets removed, breaking my manifest" is that mine is much more painful
because an update breaks changing a working system.

In my scenario I don’t just see "oh, this doesn’t work, let’s choose
another way", but a way I’ve been using and building on gets broken.

Also I experienced that at least twice already. That I had to go and
investigate before I could add a package to my manifest, because the
manifest was broken by a removed package. In at least one instance I had
not been able to update for several weeks before that and didn’t have
time and energy to investigate.

Once I had missed that my system had not updated in months, because I
did reconfigure in a cron job and a removed package had broken
/etc/config.scm


And we actually select for such breakage, because I cannot see locally
whether a package failed on CI, so while I can see (and have to fix)
packages that fail locally, on-CI-failures are invisible.


So instead of removing a package, I think the first step in a process
should be to warn everyone with that package in the manifest that it’s
broken on CI ⇒ add a warning to that package, like the rename warnings.

If no one takes it up for a few months, replace it with a
removed-package placeholder that warns to clean up the manifest. And
just keep that placeholder in place to avoid breaking manifests.


Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

signature.asc
Description: PGP signature