Hi Rebecca,
I was wondering about what to do yesterday, and decided that I was not
convinced that deviation from upstream is needed and if I were wrong,
somebody would step in. So please feel free too go ahead.
One explanation for my behaviour is that I have been running hundreads
of routine updates and that has let me seen that every patch is a toxic
asset. They eat time unpredictably (except for those who live near time
stamps; those you can be sure that any routine update you are going to
have to edit them by hand). If we let them them accumulate they will
paralyse us little by little. Dirk's external repositories are mostly
patchless and probably have more satisfied users than our packages.
Here is a point to point answer to your questions in case it is useful.
Le Sun, May 04, 2025 at 08:01:25PM +0100, Rebecca N. Palmer a écrit :
Where did you find 30s? The places I've seen timeout errors are:
I have seen a value of 30 at the following line. That is obviously
not enough for a strong conclusion. I am sorry if I was wrong and
wasted people time.
https://github.com/r-lib/httr2/blob/main/tests/testthat/helper-promise.R#L2
some of the failures were synchronised on some architecture (like
failing on the same day in amd64 and arm64)
What does this refer to? I don't see any failures on those, except
when there was (plausibly) a real bug (e.g. r-cran-rlang/1.1.5-2).
For instance 1.0.0-1 has failed migration-reference/0 on 2024-01-04 06:36:10 UTC
and 2023-12-07 03:45:08 UTC on amd64 and arm64, but passed on 2023-12-09
22:39:47 UTC
and 2024-01-05 01:35:14 UTC on armel. There is at least one more
example like this in earlier years.
Have a good day!
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work, https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy
