We need an RFC procedure [Re: Services can now have a default value]

[ng0 <contact.ng0@cryptolab.net>]

Carlo Zancanaro transcribed 2.2K bytes:
> On Fri, Apr 21 2017, Ludovic Courtès wrote:
> > A ‘define-service-type’ macro or similar could generate either code the
> > current framework (with <service-type> and <service> and
> > <foo-configuration>) or for SRFI-99-style records if we later to go that
> > route.
> >
> > So I think we should start by designing this macro.
> >
> > How does that sound?
> 
> Great! I think that it's sensible to not break things for now, and we
> should be able to design the macro to do that.
> 
> I'll have a go at it later today and see what I can come up with. (I'm
> not very familiar with guile/scheme libraries, but I have played around
> a fair bit with macros.)
> 
> > Well I don’t know, perhaps in some cases it might make sense to
> > automatically instantiate things depended on.  The advantage is that as
> > a user of the service (exim for instance) you don’t have to be aware of
> > the services it expects (improves separation of concern).
> >
> > So you could blissfully write just:
> >
> >   (cons (service mediagoblin-service-type)
> >         %base-services)
> >
> > and behind the scenes it would add an nginx instance, an mcron instance
> > with a couple of jobs, a rottlog instance, and so on.
> >
> > WDYT?
> 
> My main concern would be making sure that all of our services have safe
> defaults that can be extended. It may lead to surprising outcomes if we
> have services spun up which do more than you expect. As an example, if
> someone requests exim to start as a dependency, we should make sure it
> doesn't turn you into an open relay by default.
> 
> Carlo

On the matter of 'not breaking things':

I want an formal, publicly tracked (not *just* on the mailinglist) RFC (like in Rust or similar projects) procedure for all things which
can break currently existing configurations. Introducing these changes would
require to document properly what needs to changed so that people can read
about how to fix the mistakes.
Right now to me it seems as if people are mostly talking about such development on IRC or
offlist and then the changes are applied after a QA which sometimes takes a bit of
"don't break stuff" in consideration but is never able to grasp the full effect of
breakage.

The current error output of Guix is not enough if you simply want to do
an update of a system.
If you take a look from the perspective of someone who just wants to
administrate a mailserver, and we break their config by a simple change
of how things are written, the resulting error when you run guix system reconfigure
requires some understanding of Guix and Guile.

And please don't derail this by saying that it's currently beta status. If we are
aiming for general purpose and server adoption, we should look at problems and
solutions from all perspectives.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/