(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