all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Amirouche Boubekki <amirouche.boubekki@gmail.com>
To: dan_partelly@rdsor.ro, mail@cbaines.net, guix-devel <guix-devel@gnu.org>
Subject: Re: Ensuring we don't break user systems
Date: Mon, 30 Jul 2018 23:24:08 +0200	[thread overview]
Message-ID: <CAL7_Mo8fbvO0B4RF7qUkpYg1-vFPYWEzGmcpPr8rzf1BdkBg8w@mail.gmail.com> (raw)
In-Reply-To: <20180730211633.33mrqsr3zevljboo@abyayala>

[-- Attachment #1: Type: text/plain, Size: 3512 bytes --]

Le lun. 30 juil. 2018 à 23:17, Nils Gillmann <ng0@n0.is> 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 <dan_partelly@rdsor.ro> 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.


> > > 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.
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 4107 bytes --]

  reply	other threads:[~2018-07-30 21:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-29  9:40 Ensuring we don't break user systems Julien Lepiller
2018-07-29  9:45 ` Pierre Neidhardt
2018-07-29 16:58   ` Dan Partelly
2018-07-29 16:51 ` Dan Partelly
2018-07-29 17:28   ` Christopher Baines
2018-07-29 17:59     ` Dan Partelly
2018-07-30 21:16       ` Nils Gillmann
2018-07-30 21:24         ` Amirouche Boubekki [this message]
2018-07-30 21:30           ` Nils Gillmann
2018-07-31  6:17         ` Dan Partelly
2018-07-31  7:45           ` Julien Lepiller
2018-07-29 17:51   ` Julien Lepiller
2018-07-29 18:07     ` Dan Partelly
2018-07-29 23:41 ` Ludovic Courtès
2018-07-30  6:33   ` Dan Partelly
2018-07-30 10:58   ` Hartmut Goebel
2018-07-31 12:40     ` Pjotr Prins
2018-07-31 13:15       ` Clément Lassieur
2018-07-31 13:18         ` Julien Lepiller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAL7_Mo8fbvO0B4RF7qUkpYg1-vFPYWEzGmcpPr8rzf1BdkBg8w@mail.gmail.com \
    --to=amirouche.boubekki@gmail.com \
    --cc=dan_partelly@rdsor.ro \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.