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

[Csepp <raingloom@riseup.net>]

(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@gmail.com> writes:

> Hi,
>
> On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer <maxim.cournoyer@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.)