[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network
From: |
Attila Lendvai |
Subject: |
[bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging. |
Date: |
Mon, 09 May 2022 12:34:40 +0000 |
> ... but if there's some kind of bug, why not just report and fix it?
realistically? because there are years old issues, and long bitrotten
patches in every project's issue tracker, Guix included.
i think an importer, that does proper logging, and finishes with a 99%
correct result, is worth much more than one that barks at the first
error, and then refuses to continue processing the 100+ remaining
entries.
this was true even in my own case, when i also had the maintainer hat
on, i.e. i was already neck deep into fixing the importer.
> > and the user gets 99% of the packages imported, and has to do only
> > one package by hand.
>
>
> If the bug is fixed, then no packages need to be done by hand and other
> people will benefit as well. Whereas if it's only for 1% and the
> backtrace only happens for recursive import and not for non-recursive
> or manual import, then I'd think that the chance that the user actually
> reports or fixes the bug decreases a lot.
the tradeoff is this: what leads to a lower level of overall annoyance of all
the parties involved:
1) have a tool that is less useful, and through that it annoys the
users to report issues, which then (hopefully) thrusts some people
towards improving the tool... or
2) have a tool that does its best to produce the most useful output.
short of hard data, this can be argued forever. my intuition is clearly
pointing towards 2), because i doubt that the choking point of improving the
importer is due to not having enough examples on which it breaks.
does it make enough sense to justify my proposed behavior?
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Communism doesn’t work because people like to own stuff.”
— Frank Zappa (1940–1993)
- [bug#55242] [PATCH 01/10] guix: import: Print the number of packages at the end., Attila Lendvai, 2022/05/03
- [bug#55242] [PATCH 02/10] guix: import: go: Rename go.pkg.dev-info to pkg.go.dev-info., Attila Lendvai, 2022/05/03
- [bug#55242] [PATCH 06/10] guix: import: go: Add a local duplicate of http-fetch., Attila Lendvai, 2022/05/03
- [bug#55242] [PATCH 03/10] guix: import: go: Add mockup logging facility., Attila Lendvai, 2022/05/03
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Attila Lendvai, 2022/05/03
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Maxime Devos, 2022/05/03
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Attila Lendvai, 2022/05/03
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Maxime Devos, 2022/05/03
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging.,
Attila Lendvai <=
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Maxime Devos, 2022/05/09
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Attila Lendvai, 2022/05/09
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Maxime Devos, 2022/05/09
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Maxime Devos, 2022/05/03
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Maxime Devos, 2022/05/03
- [bug#55242] [PATCH 07/10] guix: import: go: More resilience wrt network errors; add logging., Maxime Devos, 2022/05/03
[bug#55242] [PATCH 09/10] guix: import: go: module-name -> module-path to be consistent, Attila Lendvai, 2022/05/03
[bug#55242] [PATCH 10/10] guix: import: go: Better handling of /v2 in the module path., Attila Lendvai, 2022/05/03
[bug#55242] [PATCH 04/10] guix: import: go: Fix the interpretation of the replace directive., Attila Lendvai, 2022/05/03