Re: Ensuring we don't break user systems

[Julien Lepiller]

Le Sun, 29 Jul 2018 19:51:29 +0300,
Dan Partelly <address@hidden> a écrit :

> I pointed this out 4-5 weeks ago when trying GuixSD, on this very
> list. Thanks for reaffirming  the idea In all honesty the current
> model is very badly broken, and you should not wait for 1.0. I had no
> other Linux distro break up faster than GuixSD. A stable branch is
> not enough by itself,  (but is the mort important part) you need to
> ensure that all substitutes are built correctly, and atomically
> update all substitutes following a successful build of all packages. 
> 
>  You should not inflict  current model on your users , not  even for
> an 0.1

Actually, this proposal has the side effect that anyone pulling to
stable will have all their substitutes available if the packages they
want were built at some point in time. This means that upgrading a
system or profile will always succeed and use substitutes, but it
doesn't give any guarantee on adding a package to the system or a user
profile.

> 
> 
> 
> > On Jul 29, 2018, at 12:40, Julien Lepiller <address@hidden>
> > wrote:
> > 
> > Hi guix!
> > 
> > I recently had an idea about how we should organize ourworkflow for
> > post 1.0. The goal is to ensure that users can always update their
> > system.
> > 
> > Currently, we push updatesto master and they may not build on other
> > architectures or break dependant packages. This is bad because a
> > security update might get blocked because an unrelated package now
> > fails to build.
> > 
> > I'd like to propose the following policy:
> > 
> > We wouldcreate a new branch, stable, that would be used by guix
> > pull. We would continue to push to master or other branches.
> > 
> > Once hydra finds it can build at least as many packages in master
> > than stable, it would make master the new stable, hopefully once a
> > day or so.
> > 
> > Security updates would be provided to users by a seéarate channel,
> > to ensure important updates are delivered immediately to users.
> > 
> > Another possibility is to use a patch management system like gerrit
> > with a similar policy.
> > 
> > WDYT?
> >