(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 <[email protected]> writes: > Hi, > > On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer <[email protected]> > 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.)
