Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Vincent Legoll <vincent.legoll@gmail.com>]

Hello,

On Tue, Mar 16, 2021 at 9:53 PM Tobias Geerinckx-Rice <me@tobias.gr> wrote:
> Wow, Léo.  You've done some seriously impressive CVE squashing in
> such a short timespan, and I'm very grateful to have you on board.

Yes, impressive, I have been following the repology page about potentially
vulnerable & upgradable packages for Guix, and the number has significantly
decreased the last weeks, kudos !

I did some package updates (chosen from the very same page) but unlike
you, I only cherry-picked the low hanging fruits from there and punted on
the more involved ones. A good part of that ended on core-updates due to
the rebuilds needed.

I think we really should be shortening our releases cycles (core-updates,
staging merges), because piling upon those branches for too long increase
the disruption in a way that is probably more exponential than linear.

My perception is the following (please correct me if I'm wrong):

A graft involves work on master for the inherited package & graft, sometimes
an update of the package on core updates, then the cleanup (which are more
or less all done in a short time frame when we want to release). So while it
may good enough for some fixes, they should be limited in number and in time,
which also comes to the release early, release often (in a reasonable way).

I was told that we can always update packages because guix easily allows
anyone to go back to a working state, the same reasoning should be applicable
to staging and core-updates merging. Why delay them for too long if
the potential
disruption is mitigated by going back to a workinig profile or system generation
(modulo the substitute availability which is almost only a compute resource
problem)

Cheers

-- 
Vincent Legoll