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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> (I did not receive the e-mails from Andy Tai and 宋文武, I had to look
> at <https://issues.guix.gnu.org/65391>.)
>
>> Maybe we can automatically report the failures as bugs, say every 7
>> days, and remove a package if it still fail to build in 90 days?
>
> The first part looks reasonable to me (though I would decrease 7 days
> to daily or even hourly, as I don't see a point in the delay), but how
> does the second part (removing packages) make sense at all?
>
> I mean, if you do that:
>
>   1. Build failures happen (independent of whether you do that).
>   2. Hence, by doing that, the distro shrinks over time.
>   3. Leading to frustrated users(*), because the packages they were
>   using and which were working well were suddenly removed for no good
>   reason (**).
>   4. Leading to less people fixing build failures (because of the
>   frustration).

We could bump the expiry time to 180 days, or even 365 days (a full
year).  If nobody opens an issue for a broken package in that amount of
time, it's probably not used much if at all and may not be worth the
maintenance burden.  It can always be resurrected from the git history
if someone is motivated to pick it up.  Looking for removed packages
from the git history could become a second instinct if this was made
policy.  We already have a yasnippet snippet that automates commit
message for package removal: 'remove... TAB', which makes it easy to
search for:

--8<---------------cut here---------------start------------->8---
git log --grep='gnu: Remove'

commit 72abf72062f0e813efb633e05b42c99c4bc78cff
Author: Maxim Cournoyer <me>
Date:   Fri Aug 11 21:29:54 2023 -0400

    gnu: Remove qtquickcontrols2.
    
    * gnu/packages/qt.scm (qtquickcontrols2): Delete variable.
    (pyotherside) [inputs]: Remove qtquickcontrols2.
[...]    
--8<---------------cut here---------------end--------------->8---

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.

> which seems rather counter-productive to me.
>
> (I suppose the feedback loop eventually stabilises by ‘less people ->
> less changes made to Guix -> less new build failures -> less
> frustration’, but that's not really a good thing.)
>
> Instead, what about:
>
>> Maybe we can automatically report the failures as bugs, say every
>> hour, and revert the commit(s) causing the new build failures if they
>> haven't been fixed in a week.


> (3 months seems to have to high a chance of merge conflicts and
> decreased motivation to fix the mistakes to me.)
>
> Expanding upon this a bit more:
>
>    * Expecting that people fix build failures of X when updating X seems
>      reasonable to me, and I think this is not in dispute.
>
>    * Expecting that people using X fix build failures of X or risk the
>      package X being deleted when someone else changed a dependency Y of
>      X seems unreasonable to me.   More generally, I am categorically
>      opposed to:
>
>      ‘If you change something and it breaks something else, you should
>      leave fixing the something else to someone (unless you want to
>      fix it yourself).’
>
>      (I can think of some situations where this is a good thing, but not
>      in general and in particular not in this Guix situation.)
>
>      I mean, I don't know about you, but for me it fails the categorical
>      imperative and the so-called Golden Rule.

I think we can all assume contributors are acting in good faith and
are ready to fix any problems resulting from their installed changes;
but they need to be made aware of these failures.

Which to me suggests we (again) need better tooling (that's already
improved much with the QA service, thanks to Christopher's efforts).

It can still be improved; the QA could for example notify contributors
by email when their patch or series have broken something, like the CI
of forges typically do, or other UI improvements to make it easier to
see what has been broken.  Cuirass in particular would benefit from a
status:failed-new (freshly broken) query ability.  I think the data is
already there, it just needs to be exposed.

I've opened new feature requests for the CI to help with that:
https://issues.guix.gnu.org/65594 ("[feature] [qa] Notify users by email
of problems") and https://issues.guix.gnu.org/65595 ("[feature]
[cuirass] Add ability to filter builds for status:failed-new").

Thanks for weighing in!

-- 
Thanks,
Maxim