On Wed, Aug 20, 2025 at 3:17 PM Andreas Enge <andr...@enge.fr> wrote: [...] > It will save build farm resources for packages that we already know to fail. > And it enables us to see what breaks when making a change, by statelessly > looking at what is broken, because almost by definition it worked before.
It's almost understated here: CI and local builds require manually checking upstream with `guix weather`. QA has the logic to compare package state and also compensates for intermittent failures by retrying builds three (or more!) times. And each build starts from scratch as the model provides no snapshotting or process isolation between phases. On Thu, Aug 21, 2025 at 1:56 AM Maxim Cournoyer <maxim.courno...@gmail.com> wrote: [...] > > +1 to a GCD. Ideally the surprises could be automated away. > > Don't we already have a deprecation policy? What's missing from it? I > don't think a GCD is needed to adjust our policy, if needed, especially > if it's to relax it. One objective could be to move the surprise "left of removal" to the point where builds are failing, in particular on team-feature branches. Given a manifest and optional channel, with `guix build --dry-run` we can obtain a list of unavailable packages. But we want to know 1) when a substitute is unavailable and 2) the root cause, i.e. whether and which of the package or dependencies is broken. And we cannot expect users to continuously monitor branch state, so notifications would be nice. Greg
