[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tricking peer review
From: |
Ludovic Courtès |
Subject: |
Re: Tricking peer review |
Date: |
Mon, 18 Oct 2021 09:40:11 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi Ryan,
Ryan Prior <rprior@protonmail.com> skribis:
> I've suggested this before and this seems like a good time to bring it
> up again: can we create a database of known "bad" Guix commit hashes,
> and make time-machine fetch the list and warn before it'll visit one
> of those hashes? This would resolve the land-mine problem and
> generally de-risk our git tree, which is maintained by fallible
> volunteers who will occasionally push tragic commits.
How would we define “bad” though?
By definition, packages found in past Guix revisions are missing
features, have unfixed bugs and unpatched security vulnerabilities.
Yet, pinning the Guix revision or re-deploying a past revision as-is has
its uses and I’d say it’s a key feature, even.
I don’t think there are “tragic” commits either. Usually, one records a
revision that works for them and use the same months later.
Thanks,
Ludo’.
- Tricking peer review, Ludovic Courtès, 2021/10/15
- Re: Tricking peer review, Liliana Marie Prikler, 2021/10/15
- Re: Tricking peer review, Ryan Prior, 2021/10/15
- Re: Tricking peer review,
Ludovic Courtès <=
- Re: Tricking peer review, Ryan Prior, 2021/10/18
- Re: Tricking peer review, zimoun, 2021/10/19
- Re: Tricking peer review, Leo Famulari, 2021/10/20
- Re: Tricking peer review, zimoun, 2021/10/21
Re: Tricking peer review, Thiago Jung Bauermann, 2021/10/15
Re: Tricking peer review, Ludovic Courtès, 2021/10/18
Re: Tricking peer review, zimoun, 2021/10/19