From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nils Gillmann Subject: Re: Ensuring we don't break user systems Date: Mon, 30 Jul 2018 21:16:34 +0000 Message-ID: <20180730211633.33mrqsr3zevljboo@abyayala> References: <28F9E4E7-AA66-43E7-8A68-AC3E46B60959@lepiller.eu> <1C89A082-845D-49B4-A70F-D4FFCD411124@rdsor.ro> <871sbmkl3p.fsf@cbaines.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkFWE-0002Wa-5c for guix-devel@gnu.org; Mon, 30 Jul 2018 17:15:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkFWC-0004tB-VV for guix-devel@gnu.org; Mon, 30 Jul 2018 17:15:54 -0400 Received: from conspiracy.of.n0.is ([2a01:4f8:1c0c:7ad0::1]:55424) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fkFWC-0004so-Lm for guix-devel@gnu.org; Mon, 30 Jul 2018 17:15:52 -0400 Content-Disposition: inline In-Reply-To: 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 Cc: guix-devel@gnu.org 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 introdu= ced during development. Having the update to the package manager (which in = GuixSD is very central to the distro itself)=20 > result in a broken system "even if you can roll back=E2=80=9D is a very b= ad 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 b= ad ( having the package manager crap on itself due to bugs introduced in th= e 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 w= aste 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 no= t expose people to your devel branch where they will get first contact wiit= h guix bugs and guile bugs. The situation with GuixSD is somehow complicate= d by the fact that the package metadata is compiled as code, but yeah, a st= able branch which is proven to be compilable and preferably regression test= ed 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. >=20 > And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a lot. Th= at is a fact, unfortunately.=20 > > Dan Partelly writes: > >=20 > >> I pointed this out 4-5 weeks ago when trying GuixSD, on this very list= =2E Thanks for reaffirming the idea In all honesty the current model is ve= ry badly broken, and you should not wait for 1.0. I had no other Linux dist= ro 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 success= ful build of all packages. > >>=20 > >> You should not inflict current model on your users , not even for an= 0.1 > >=20 > > 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. > >=20 > > Saying that something doesn't work for you is fine, and can be helpful, > > but such a unevidenced extreme view is unhelpful. >=20 >=20