Léo Le Bouter <lle-bout@zaclys.net> writes:

> On Fri, 2021-03-26 at 22:13 +0000, Christopher Baines wrote:
>> Can you clarify what specific problem or problems you're proposing
>> this
>> security-updates branch to address?
>
> Substitute availability of security updates when they are released,
> without causing big rebuilds on master for users before the build farm
> had time to produce substitutes.

Ok.

>> You mention applying and backporting patches is lots of work, and
>> uncertainty around whether grafts work in particular
>> situations.
>
> Also that some times backporting is just not possible because security
> fixes are not properly labeled upstream as security-relevant and manual
> review of each and every commit is just not viable.
>
>> Personally I think staging and core-updates are quite a bit of work,
>> and
>> adding more complexity to the process involves more work in my
>> mind. Additionally, this isn't going to provide more information
>> about
>> areas where grafts can't be used (if those exist).
>
> I understand. There's lot of uncertainty on how grafts work exactly for
> me and in what situations they work and what situations they do not.
> The only way I am certain some security fix is correctly applied in GNU
> Guix is when the vulnerable version of the package is not packaged at
> all anymore in GNU Guix.
>
>> Now the software involved is getting better at rapidly building
>> things
>> for substitutes, personally I see a way forward through trying to
>> measure and potentially increase the rate of change for outputs in
>> general. Going faster also involves more work probably, but in terms
>> of
>> the process, that might just mean that updates to more packages can
>> be
>> merged to master directly, without sitting on a non-master branch.
>
> I would like this, merging things to master directly when we feel it is
> the right thing would be what I would like to do. Even if it causes big
> world rebuilds, when we can't graft.
>
> There's another thing I saw that was ongoing but can't remember where,
> that 'guix pull' could hold off updating to newer revisions unless
> substitutes are available.

I think approaching the substitute availability problem this way, and
supporting users delaying updates if they want to is the way to go, at
least to avoid process on the side of making changes.

I'm hoping things will get better through a combination of these
factors:

 - Measuring the "churn" in Guix, which will hopefully allow for
   intentionally increaseing this

 - Keeping packages more up to date generally

 - Allowing users to choose whether they want the latest packages, or
   want to avoid building things (this means important security updates
   that cause rebuilds can be merged to master)