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

[Leo Famulari]

On Mon, May 22, 2017 at 11:23:23PM +0200, Ricardo Wurmus wrote:
> Ludovic Courtès  writes:
> > What would be stable in the “stable branch”, packages or Guix?  :-)
> >
> > A branch where Guix itself is stable would be nice, though it would need
> > careful merging from master regularly.
> 
> This would make sense.  It would require some restraint in moving
> packages to different modules or breaking some underlying package
> features, which would cause ABI breakage.
> 
> I do think it would be possible, though.

It's definitely possible, but I'd like to see it proposed in more detail
by the group that will maintain it. It's not okay to start a "stable
branch" unless it will be properly supported.

> 
> > A branch where packages are stable (à la Debian stable) would be too
> > much work (I’m even skeptical it makes any sense given that many
> > declared and undeclared security vulnerabilities get patched everytime a
> > piece of software is released…).
> 
> Yeah, that wouldn’t make sense.  It’s hard enough to deal with security
> issues in current software in a timely fashion.

+1

Anyone who really needs this has a business use case that can support a
private fork, in my opinion.


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Petter  skribis:

> If I may make a suggestion, coming from a place of ignorance.
>
> How about a stable branch that would be opt-in?

What would be stable in the “stable branch”, packages or Guix?  :-)

A branch where Guix itself is stable would be nice, though it would need
careful merging from master regularly.

A branch where packages are stable (à la Debian stable) would be too
much work (I’m even skeptical it makes any sense given that many
declared and undeclared security vulnerabilities get patched everytime a
piece of software is released…).

Ludo’.

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

[Petter]

If I may make a suggestion, coming from a place of ignorance.

How about a stable branch that would be opt-in?

On Thu, 27 Apr 2017 15:29:53 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Ricardo Wurmus  skribis:
> 
> > It’s a little unfortunate that packages are developed together with
> > everything else, because this means that there is no way for people to
> > opt out of breaking changes until the next release without also opting
> > out of getting any updates at all.  
> 
> It’s both a strength and a weakness I guess.  The good thing is that we
> can make changes that affect everything at once.  The bad thing is what
> you mention.
> 
> We could use feature branches more, with the downside that they would
> probably get little additional testing, precisely because one would have
> to choose between features and packages.
> 
> Thoughts?
> 
> Ludo’.
> 

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

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> It’s a little unfortunate that packages are developed together with
> everything else, because this means that there is no way for people to
> opt out of breaking changes until the next release without also opting
> out of getting any updates at all.

It’s both a strength and a weakness I guess.  The good thing is that we
can make changes that affect everything at once.  The bad thing is what
you mention.

We could use feature branches more, with the downside that they would
probably get little additional testing, precisely because one would have
to choose between features and packages.

Thoughts?

Ludo’.

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

[ng0]

Ricardo Wurmus transcribed 1.0K bytes:
> 
> Ludovic Courtès  writes:
> 
> > As for posting the change before applying it, I should do more of that.
> > I’ve taken the bad habit of pushing what I consider as “simple” changes
> > directly to the repo, but perhaps the criteria should be reconsidered.
> > :-)
> 
> I think it’s fine to push simple changes directly.  There hasn’t been a
> single instance when you pushed something where I thought that it
> shouldn’t have been pushed.
> 
> Between releases we are free to change things; they only have to be
> mentioned in the ChangeLog for the next release.  ABI breakage can get a
> little annoying if one doesn’t know about it and the compilation fails
> with unclear errors.
> 
> It’s a little unfortunate that packages are developed together with
> everything else, because this means that there is no way for people to
> opt out of breaking changes until the next release without also opting
> out of getting any updates at all.
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net

In my opinion it is simple as long as nothing else is affected (or affected
parts are changed at the same time). In other words, if it touches
the way services, packages etc are compossed or definitions which (canonically)
happen to be in the system config, it should be communicated in advance.

I think almost no change Ludovic commited in the time I'm involved broke 
something,
even if it wasn't simple changes.
To discuss changes doesn't hold them back, it gives others a clear view
on what is happening, on the intentions and maybe to help fix mistakes
in advance.
I don't think anyone produces intenionally bad code, it's just a difference
if you develop in reaction to changes you only know about once they are pushed
(or once feature branches are completed) or if you can discuss about them.
In the first case it's an isolated effort which ressembles a group to the 
outside,
in the second case it's getting closer to community work.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

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

[ng0]

Ludovic Courtès transcribed 1.7K bytes:
> Hi ng0,
> 
> ng0  skribis:
> 
> > Let's take this thread, starting at
> > "https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00329.html;.
> > Ludovic worked on something, pushed it, did some changes to the relevant
> > documentation but further examples in the documentation which are now
> > affected weren't fixed with the push. We spent time answering questions
> > about broken configurations, assuming everyone who uses GuixSD now and
> > in the future has a fairly competent knowledge of Guile, explaining changes
> > which could have been avoided - or at least reduced in frequency of 
> > questions
> > asked - by changing examples.
> 
> I think there’s a misunderstanding.  This change is what started the
> discussion we’re having with Carlo, but it is a compatible change:
> GuixSD configs that previously worked still do.

Yep, sorry. I figured out that much after having my GuixSD based mailserver
running. Cause and Reaction, okay... but what I've asked about still stands
on its own, it would be better if certain changes are discussed and we come
up with a solid system of announcing changes in case they should break 
something.
I like how Gentoo and Archlinux solved it.

> Thus I don’t think anyone spent time “answering questions about broken
> configurations” in this case.  For the same reason, examples in the doc
> that were valid before are still valid after the change.
> 
> > If Ludovic would've presented this change before applying it, it would've
> > been one of the obvious problems: don't just document the change, change
> > further documentation sections which rely on this. This way we don't have
> > a documentation which presents people examples but contradicts itself later
> > on.
> 
> What part of the documentation contradicts itself?  I’m confused.

None, the message you initially wrote about the change could've been less
implicit. Like "In addition to $OLD you can now write $NEW, $OLD is still
valid and will work".

> As for posting the change before applying it, I should do more of that.
> I’ve taken the bad habit of pushing what I consider as “simple” changes
> directly to the repo, but perhaps the criteria should be reconsidered.
> :-)
> 
> Thoughts?
> 
> Ludo’.
> 

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

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

[Ricardo Wurmus]

Ludovic Courtès  writes:

> As for posting the change before applying it, I should do more of that.
> I’ve taken the bad habit of pushing what I consider as “simple” changes
> directly to the repo, but perhaps the criteria should be reconsidered.
> :-)

I think it’s fine to push simple changes directly.  There hasn’t been a
single instance when you pushed something where I thought that it
shouldn’t have been pushed.

Between releases we are free to change things; they only have to be
mentioned in the ChangeLog for the next release.  ABI breakage can get a
little annoying if one doesn’t know about it and the compilation fails
with unclear errors.

It’s a little unfortunate that packages are developed together with
everything else, because this means that there is no way for people to
opt out of breaking changes until the next release without also opting
out of getting any updates at all.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Ludovic Courtès]

Hi ng0,

ng0  skribis:

> Let's take this thread, starting at
> "https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00329.html;.
> Ludovic worked on something, pushed it, did some changes to the relevant
> documentation but further examples in the documentation which are now
> affected weren't fixed with the push. We spent time answering questions
> about broken configurations, assuming everyone who uses GuixSD now and
> in the future has a fairly competent knowledge of Guile, explaining changes
> which could have been avoided - or at least reduced in frequency of questions
> asked - by changing examples.

I think there’s a misunderstanding.  This change is what started the
discussion we’re having with Carlo, but it is a compatible change:
GuixSD configs that previously worked still do.

Thus I don’t think anyone spent time “answering questions about broken
configurations” in this case.  For the same reason, examples in the doc
that were valid before are still valid after the change.

> If Ludovic would've presented this change before applying it, it would've
> been one of the obvious problems: don't just document the change, change
> further documentation sections which rely on this. This way we don't have
> a documentation which presents people examples but contradicts itself later
> on.

What part of the documentation contradicts itself?  I’m confused.

As for posting the change before applying it, I should do more of that.
I’ve taken the bad habit of pushing what I consider as “simple” changes
directly to the repo, but perhaps the criteria should be reconsidered.
:-)

Thoughts?

Ludo’.

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

[ng0]

Ricardo Wurmus transcribed 0.7K bytes:
> 
> ng0  writes:
> 
> > 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.
> 
> […]
> 
> API changes are usually explained in the release announcement’s
> changelog.  This doesn’t really help between releases, though.  So,
> either we release more often (yay!) or we support the old APIs until the
> next release (boo!).

Okay, then let me be more specific as you skipped the last part of the
message, which explained my intention.

Let's take this thread, starting at
"https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00329.html;.
Ludovic worked on something, pushed it, did some changes to the relevant
documentation but further examples in the documentation which are now
affected weren't fixed with the push. We spent time answering questions
about broken configurations, assuming everyone who uses GuixSD now and
in the future has a fairly competent knowledge of Guile, explaining changes
which could have been avoided - or at least reduced in frequency of questions
asked - by changing examples.
If Ludovic would've presented this change before applying it, it would've
been one of the obvious problems: don't just document the change, change
further documentation sections which rely on this. This way we don't have
a documentation which presents people examples but contradicts itself later
on.
I'm pretty sure I don't have to tell you that casual users would not waste
their time with getting to the solution, and admins want something which in
case of breakage documents the changes before they happen.

Announcing the changes after the discussion about the changes happened is
another thing.
Gentoo sent out "Mails" (local mail) which was then displayed and kept in
the system of the user and it would be visible in the portage (comparable
to "guix package") application.
A bug report on "oh no, my system imploded!" would then ask, have you read
the announcement message?
And archlinux does it in a similar fashion, for both systems changes are
made visible in news on the website.

Even when we would have a "stable" and "unstable" variant, documenting changes
and explaining how to solve problems arising from them should come natural and
in our case it shouldn't involve implied conclusions but rather a good set
of examples.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

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

[Ricardo Wurmus]

ng0  writes:

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

[…]

API changes are usually explained in the release announcement’s
changelog.  This doesn’t really help between releases, though.  So,
either we release more often (yay!) or we support the old APIs until the
next release (boo!).

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[ng0]

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  and  and
> > ) 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/