[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: We need an RFC procedure [Re: Services can now have a default value]
From: |
ng0 |
Subject: |
Re: We need an RFC procedure [Re: Services can now have a default value] |
Date: |
Sun, 23 Apr 2017 11:52:50 +0000 |
Ludovic Courtès transcribed 1.7K bytes:
> Hi ng0,
>
> ng0 <address@hidden> 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: Services can now have a default value, (continued)
- Re: Services can now have a default value, Ludovic Courtès, 2017/04/21
- Re: Services can now have a default value, Carlo Zancanaro, 2017/04/21
- We need an RFC procedure [Re: Services can now have a default value], ng0, 2017/04/21
- Re: We need an RFC procedure [Re: Services can now have a default value], Ricardo Wurmus, 2017/04/22
- Re: We need an RFC procedure [Re: Services can now have a default value], ng0, 2017/04/22
- Re: We need an RFC procedure [Re: Services can now have a default value], Ludovic Courtès, 2017/04/22
- Re: We need an RFC procedure [Re: Services can now have a default value], Ricardo Wurmus, 2017/04/23
- Re: We need an RFC procedure [Re: Services can now have a default value], ng0, 2017/04/23
- Re: We need an RFC procedure [Re: Services can now have a default value], Ludovic Courtès, 2017/04/27
- Re: We need an RFC procedure [Re: Services can now have a default value], Petter, 2017/04/27
- Re: We need an RFC procedure [Re: Services can now have a default value],
ng0 <=
- Re: Services can now have a default value, Christopher Allan Webber, 2017/04/22
- Re: Services can now have a default value, Jan Nieuwenhuizen, 2017/04/22
- Re: Services can now have a default value, Ludovic Courtès, 2017/04/22