toward a plan? (was Re: Reducing "You found a bug" reports)

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

As Ian pointed out earlier, here some “guix pull” bugs:

    55066
    58309  closed
    61520  closed
    62023  closed
    62830

And most of them are transient or hard to reproduce.  More had been
listed in [1], it reads:

    63451
    63830
    64489
    64659  v1.4.0
    64753
    64963

And it’s often the same: transient or hard to reproduce.  Here a larger
collection continuing…

    64753
    65495
    65549
    65560  v1.4.0
    66600  v1.4.0
    67035
    67179  v1.2.0
    67482
    67806  v1.4.0
    67956  v1.2.0
    67965  v1.4.0
    68397  v1.4.0
    69127  v1.4.0
    69334
    69726  v1.3.0
    70075  v1.3.0
    70192
    70200  v1.4.0
    70201  v1.4.0
    70297  v1.3.0
    70646  v1.4.0
    70649
    70650  v1.4.0
    70651
    70658  v1.4.0
    70667
    70681  v1.3.0
    70940
    71426
    71437  v1.4.0
    71691  v1.4.0
    71908
    71945
    72028  v1.4.0
    72100
    72135  upgrade from v1.2.0    
    72332  v1.4.0
    72353  v1.4.0
    72563  v1.4.0
    72639  v1.4.0

Please note v1.4.0 means the host revision was v1.4.0.


After looking at some of these, we have 3 classes of bugs:

 1. transient
 2. pulling from too old host revision
 3. mix of both


IMHO, the next actions are:

 a) Replace this message:

--8<---------------cut here---------------start------------->8---
                      (message (format #f "You found a bug: the program '~a'
failed to compute the derivation for Guix (version: ~s; system: ~s;
host version: ~s; pull-version: ~s).
Please report the COMPLETE output above by email to <~a>.~%"
--8<---------------cut here---------------end--------------->8---

    by something like: “sorry, could you try again guix pull --commit=~s
    and report if it fails again.”


 b) Put here and there some logging [2] information.  Patch#68946 [2]
    provides logging facilities but is missing concrete user.

    It could be worth to have it.  So then, once “guix pull” fails, we
    could ask to re-run “guix pull --commit=<target> --log-level=debug”.

    This would help in having some information at failure time instead
    of asking them after.

    Moreover, it would provide information in order to diagnose all
    these transient errors and see if they could be catched up instead
    of erroring.

WDYT?

In all cases, feel free to pick one or more bugs from the list above and
investigate.  Many do not have any answer – which is not welcoming and
friendly.

Cheers,
simon



1: collection of “guix pull“ bug reports
Simon Tournier <zimon.toutoune@gmail.com>
Wed, 23 Aug 2023 18:17:20 +0200
id:86jztl20of.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-08
https://yhetil.org/guix/86jztl20of.fsf@gmail.com

2: [bug#68946] [RFC PATCH 0/1] Add logging capability to Guix
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Mon, 05 Feb 2024 23:12:00 -0500
id:cover.1707192720.git.maxim.cournoyer@gmail.com
https://issues.guix.gnu.org/68946
https://issues.guix.gnu.org/msgid/cover.1707192720.git.maxim.cournoyer@gmail.com
https://yhetil.org/guix/cover.1707192720.git.maxim.cournoyer@gmail.com