Attila Lendvai <att...@lendvai.name> writes:
My work on Guix is dominated by bulk upgrades of hundreds of R
packages. There is no point in submitting the upgrades
individually. In fact, my work on Guix has become so dominated
by
this is somewhat tangential, but guix is the first project in my
entire programmer career where it's not only allowed to commit
changes
that will break things, but it's straight out demanded (the one
commit
per package policy, even if it knowingly introduces
incompatibilities).
Your statement is false (and it sounds rather exaggerated). We do
not want commits of half-broken or broken work in the commit
history. Every commit should leave Guix in a usable state. There
are also several instances where we preferred to have one commit
for one change, even if it affects dozens of packages.
I just don't think that this is applicable when upgrading hundreds
of R packages, because I prefer being able to use the commit
history when finding the culprit of a bug (e.g. an upgrade to
r-curl that led to a bug in some other R package). And no, R
package upgrades are not a common cause of breakage. In fact I
cannot think of even one instance in the past decade where R
package upgrades led to problems for Guix.
--
Ricardo
