> > FWIW, this commit policy has always bothered me as a newcomer to
> > Guix. pretty much everywhere else it's a major offence against your
> > colleagues to commit something that breaks the build in any way.
>
>
> In the last few months I’ve repeatedly seen assertions in a similar
> style as this one. They always genuinely surprise me, and it’s probably
> not just because I’m oblivious and out of touch.
well, both point of views are reasonable. they just make different tradeoffs.
i think an abstraction is missing here, let's call it guix log for this mail.
it's something like the git log, but one that lists the buildable and
substitutable states of the guix repo.
it's probably the same thing that causes the discrepancy between git commits
and substitutes: the build servers are not building every commit of the git
repo. they pick an unpredictable (?) series of commits, skipping some
inbetween. if i guix pull, or guix time-machine to the "wrong" commit, then
i'll need to build some stuff locally. sometimes these can be heavy packages.
this hypothetical 'guix log' is probably also what's missing between a
hypothetical staging branch and master, whose role would be to make sure that
commits don't reach the users prior to having substitutes for them.
does this make sense?
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Sometimes I wonder whether the world is being run by smart people who are
putting us on or by imbeciles who really mean it.”
— Mark Twain (1835-1910)
