From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amirouche Boubekki Subject: Re: Ensuring we don't break user systems Date: Mon, 30 Jul 2018 23:24:08 +0200 Message-ID: References: <28F9E4E7-AA66-43E7-8A68-AC3E46B60959@lepiller.eu> <1C89A082-845D-49B4-A70F-D4FFCD411124@rdsor.ro> <871sbmkl3p.fsf@cbaines.net> <20180730211633.33mrqsr3zevljboo@abyayala> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a5c22405723e156d" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkFeQ-0004ig-T9 for guix-devel@gnu.org; Mon, 30 Jul 2018 17:24:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkFeP-0007Z4-GI for guix-devel@gnu.org; Mon, 30 Jul 2018 17:24:22 -0400 Received: from mail-oi0-x233.google.com ([2607:f8b0:4003:c06::233]:41292) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fkFeP-0007Yw-85 for guix-devel@gnu.org; Mon, 30 Jul 2018 17:24:21 -0400 Received: by mail-oi0-x233.google.com with SMTP id k12-v6so24015106oiw.8 for ; Mon, 30 Jul 2018 14:24:21 -0700 (PDT) In-Reply-To: <20180730211633.33mrqsr3zevljboo@abyayala> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: dan_partelly@rdsor.ro, mail@cbaines.net, guix-devel --000000000000a5c22405723e156d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le lun. 30 juil. 2018 =C3=A0 23:17, Nils Gillmann a =C3=A9crit = : > 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 manag= er > (which in GuixSD is very central to the distro itself) > > result in a broken system "even if you can roll back=E2=80=9D 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 sociall= y > 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 wasti= ng > time, and time is the most precious comodity we have. I do not want the O= S > I use to waste my time. I want to install the software I need and work wi= th > 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 i= s > 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 futur= e > 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 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 i= s > 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. > > > 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 helpfu= l, > > > but such a unevidenced extreme view is unhelpful. > > > > > > --000000000000a5c22405723e156d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2= =A0lun. 30 juil. 2018 =C3=A0=C2=A023:17, Nils Gillmann <ng0@n0.is> a =C3=A9crit=C2=A0:
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&q= uot;
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 sensib= le.=C2=A0 It is a undeniable reality of software development=C2=A0 that bug= s are introduced during development. Having the update to the package manag= er (which in GuixSD is very central to the distro itself)
> result in a broken system "even if you can roll back=E2=80=9D is = a very bad thing. It is my opinion that the current model is both technical= ly bad (exposing users to broken software , security bugs and so on) and so= cially bad ( having the package manager crap on itself due to bugs introduc= ed in the development cycle may prompt a lot of people to look in to an alt= ernative and creates bad publicity. It also results in end users wasting ti= me, 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 a= nd go on with my life and work=C2=A0 ). Ironically, the problem is easily s= olved . 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 someh= ow complicated by the fact that the package metadata is compiled as code, b= ut yeah, a stable branch which is proven to be compilable and preferably re= gression 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=C2=A0= lot. That is a fact, unfortunately.
> > Dan Partelly <dan_partelly@rdsor.ro> writes:
> >
> >> I pointed this out 4-5 weeks ago when trying GuixSD, on this = very list. Thanks for reaffirming=C2=A0 the idea In all honesty the current= model is very badly broken, and you should not wait for 1.0. I had no othe= r Linux distro break up faster than GuixSD. A stable branch is not enough b= y itself,=C2=A0 (but is the mort important part) you need to ensure that al= l substitutes are built correctly, and atomically update all substitutes fo= llowing a successful build of all packages.
> >>
> >> You should not inflict=C2=A0 current model on your users , no= t=C2=A0 even for an 0.1

You say there i= s not enough guix developpers.
=C2=A0
> > 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 usef= ul to apply
> > to Guix.
> >
> > Saying that something doesn't work for you is fine, and can b= e helpful,
> > but such a unevidenced extreme view is unhelpful.
>
>

--000000000000a5c22405723e156d--