Re: Guix infrastructure

[ng0 <ng0@infotropique.org>]

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

I have no time  at the moment for a full reply,
but I think we got off at the wrong foot Ricardo.

I guess you are trying to read between the lines
that I tried to be negative about everyones work.
I don't have any subtext.
What I could've done better is go more into detail.

Where did I get the impression of Guix and Guile being
intransparent about the bug? I opened a bug, saw one thread
on the guile mailinglist, and that's it. So given the fact
that I am not omniscient my only logical assumption was that
not much happened in public space.

The rest was run over, but we had some chats over the
weekend and our solution to our side of this is more
clear now. It's not yet ready to be published, but I'll
keep Guix in the loop.

Liam Wigney transcribed 3.4K bytes:
> Hey all,
> 
> While I'm aware it was mentioned that server power was mentioned as an issue, OpenQA might be of interest for automatic testing. 
> 
> > On 9 Jul 2017, at 6:51 pm, Ricardo Wurmus <rekado@elephly.net> wrote:
> > 
> > 
> > Hi ng0,
> > 
> >> - master is not stable and it is not being treated as a high priority
> >>  problem
> > 
> > I don’t know where you get this from and I don’t appreciate the
> > insinuation that we don’t care.  The vast majority of commits to
> > “master” are totally fine.
> > 
> > As we don’t have the resources for maintaining a stable branch, “master”
> > is a best effort.
> > 
> >> - a bug in the compiler which is used in the core of Guix is bad.
> > 
> > We all agree here.  I don’t see the point of reiterating it.  The people
> > who can fix it are already working on it — in their own time and in
> > *addition* to all the things they regularly do.
> > 
> > Here’s a shout out to Ludo who tirelessly fixes old and new bugs,
> > implements new features, improves performance, deals with GSoC, and
> > answers community questions; to Andy Wingo who continuously improves
> > Guile performance, implements new Guix services, drafted and implemented
> > the potluck faster than I could blink, …; to Leo and Mark and Marius who
> > keep on top of security issues despite the fact that this is no fun; —
> > the list goes on and on.
> > 
> > Andy and Ludo are working on the Guile bug already.  I don’t see how
> > this can reasonably result in complaints.
> > 
> >>  In my
> >>  understanding that we could at least try to evade this by reducing the
> >>  module sizes is met with arguments like "this will be fixed in the
> >>  future, for now we can only split 1 module the rest has to stay
> >>  together for semantic and linguistic reasons".
> >>  If my understanding of the whole situation is wrong this is due to the
> >>  intransparent dealing with this serious problem and the way my idea
> >>  to temporarily fix it was met.
> > 
> > “Intransparent”?  I don’t know what else to say here.
> > 
> > Breaking up modules is *not* a fix, not even a temporary fix.  How would
> > this help when Guile never frees memory and the cumulative usage ends up
> > being the same?  This is something that needs to be fixed in Guile and
> > both Andy and Ludo have already spent time to investigate this and come
> > up with solutions.
> > 
> > I also wrote that splitting up (gnu packages python) is fine – yet I
> > have not seen a patch that would do this.  There’s only so much a single
> > person can do.
> > 
> > I’m skipping the rest of the complaints in this paragraph, because they
> > add nothing new and ignore the late night efforts of people in the Guix
> > and Guile communities.
> > 
> >> - Writing system services in Shepherd is hard.
> > 
> > I beg to differ.  If you have legitimate concerns please point out the
> > sections in the manuals that are unclear and propose changes.
> > 
> >> These are the major issues Guix could fix.
> > 
> > “Guix” is people.
> > 
> > Personally, I don’t want to spend more time on this discussion, because
> > I want to get back to getting things done that probably only few people
> > will see or notice, but which need to be done anyway.
> > 
> > --
> > Ricardo
> > 
> > GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> > https://elephly.net
> > 
> > 
> 

-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]