GNU bug report logs - #65391
People need to report failing builds even though we have ci.guix.gnu.org for that

Previous Next

Full log

View this message in rfc822 format

From: Csepp <raingloom <at> riseup.net>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 65391 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>, 宋文武 <iyzsong <at> envs.net>, Bruno Victal <mirai <at> makinata.eu>, Andy Tai <atai <at> atai.org>, Csepp <raingloom <at> riseup.net>
Subject: bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that
Date: Mon, 11 Sep 2023 09:28:32 +0200

(changing the subject back to the intended one.  I think the fact that
someone replies to an automated acknowledgement email like once a week
says indicates that the emails are not communicating clearly what their
purpose is. anyways, on to the actual issue at hand.)

Simon Tournier <zimon.toutoune <at> gmail.com> writes:

> Hi,
>
> On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>
>> It's frustrating for users when a package is missing, but it's also
>> frustrating/inefficient for maintainers to stumble upon broken packages
>> when checking if an upgrade broke dependent packages (it takes time to
>> build them just to find out they fail, and researching they already
>> did), so a balance is needed.
>
> There is nothing worse as an user to have this experience:
>
>     guix search foobar
>
> oh cool, foobar is there, let try it,
>
>     guix shell foobar
>
>     … wait …
>     … stuff are building …
>     … laptop is burning …
>     … wait …
>     Bang!
>
> Keeping broken packages is just annoyances.  Contributor are annoyed
> because as said by the paragraph above.  And user are annoyed as
> described just above.
>
> I am in favor to set a policy for removing then.
>
> The question is the way to detect them.  QA can do whatever we want but
> until people are helping Chris because, IMHO, Chris is already enough
> busy to keep stuff running, we probably need to keep our process simple
> enough in order to stay actionable and avoid some vacuum of “coulda,
> shoulda or woulda”.  For what my opinion is worth on that. :-)
>
> Cheers,
> simon

That is not a package problem but a Guix interface problem.  I have been
saying for a while that there needs to be an option to disable all
non-trivial local builds by default when you know your machine can't
handle them.
Alternatively the CI could record some basic resource utilization
information, so users could for example set a limit on RAM.  (Although
this gets tricky for parallel builds.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.