[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65391: People need to report failing builds even though we have ci.g
From: |
Csepp |
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@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.)