Re: Ensuring we don't break user systems

[Nils Gillmann]

Amirouche Boubekki transcribed 7.8K bytes:
> Le lun. 30 juil. 2018 à 23:17, Nils Gillmann <address@hidden> a écrit :
> 
> > 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
> >
> 
> You say there is not enough guix developpers.

Who or what exactly are you replying to?

My understanding is: We are slowly growing to the point (conmtributor
and user wise) where we have to think about the trust people put in
us, and - even when most of us work on this as volunteers - look at
our development model (or rather how users interact with it).

But maybe you meant something else..? 
> 
> > > > 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.
> > >
> > >
> >
> >