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

[Maxime Devos]

(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).

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.

(*) making no distinction between users and developers here, as the 
latter are users too.

(**) I can think of four classes of causes of new build failures, in all 
of which removing the package usually makes no sense:

    + Non-determinism.  While fixing the non-determinism would be ideal,
      instead of removing the package, you could just retry the build.

    + Time-bombs.  These tend to be simple to fix.  Often they are in
      tests, which at worst you could simply disable, instead of
      removing the package.

    + Update of dependency that is incompatible with the dependent.

      That should be caught at review time -- if there is anything
      that should be removed, it's the update (i.e., revert it).

      Also, Guix supports having multiple versions of a package,
      you could use that?  Or if it is a simple change, you could
      patch things while things haven't diverged much yet (and
      maybe upstream even already has an update to make things
      compatible!)

    + Out-of-memory problems and the like: see non-determinism.

Best regards,
Maxime Devos

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature