Hello, On Tue, Mar 16, 2021 at 9:53 PM Tobias Geerinckx-Rice <[email protected]> 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
