Re: Ensuring we don't break user systems

[Nils Gillmann]

We just have 2 different views here.

When Guix started, which was about 3 years before I joined, the model
was okay. Between 2015 and now the amount of breakage has been
extremely reduced due to discussions about more reasonable development
models. For a while now we have an informal rfc for bigger changes -
this is a result from "please don't do that without asking first"
because some of us got upset about assuming that all changes are okay.

I sympathize with your point of view - in production even a couple of
breaking commits are bad.

We have grown over the last years, but developing reasonable deployment
models which fit our group takes time.

I'm okay with defining a branching model and use it once we have the
tooling and infrastructure for it.

Dan Partelly transcribed 2.4K bytes:
> No I did not shown or proofed this affirmation. I believe it is sensible.  It 
> is a undeniable reality of software development  that bugs are introduced 
> during development. Having the update to the package manager (which in GuixSD 
> is very central to the distro itself) 
> result in a broken system "even if you can roll back” is a very bad thing. It 
> is my opinion that the current model is both technically bad (exposing users 
> to broken software , security bugs and so on) and socially bad ( having the 
> package manager crap on itself due to bugs introduced in the development 
> cycle may prompt a lot of people to look in to an alternative and creates bad 
> publicity. It also results in end users wasting time, and time is the most 
> precious comodity we have. I do not want the OS I use to waste my time. I 
> want to install the software I need and work with and go on with my life and 
> work  ). Ironically, the problem is easily solved . DO not expose people to 
> your devel branch where they will get first contact wiith guix bugs and guile 
> bugs. The situation with GuixSD is somehow complicated by the fact that the 
> package metadata is compiled as code, but yeah, a stable branch which is 
> proven to be compilable and preferably regression tested is the first step 
> IMO towards a better future with GuixSD. Treat is as a product which offers a 
> rock solid platform for the users.
> 
> And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a  lot. That 
> is a fact, unfortunately. 
> > Dan Partelly <address@hidden> writes:
> > 
> >> 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
> > 
> > While this might apply to some software. I don't believe, and I don't
> > think you've shown that this reasoning is appropriate or useful to apply
> > to Guix.
> > 
> > Saying that something doesn't work for you is fine, and can be helpful,
> > but such a unevidenced extreme view is unhelpful.
> 
>