Closed rikhuijzer closed 3 years ago
An alternative (better?) approach would be to use CompatHelper 2 if CompstHelper 3 causes problems.
Just a heads up: I'm not completely sure what's the common practice in TuringTutorials but in most other Turing repos we follow ColPrac which requires approval of another contributor with merge rights before a PR is merged.
Yes, you're right. Usually, I do wait for approval, but this morning I got very annoyed by the CompatHelper PRs because I've worked hours and hours to get rid of those PRs.
Next time, I'll wait for review again.
Yes, you're right. Usually, I do wait for approval, but this morning I got very annoyed by the CompatHelper PRs because I've worked hours and hours to get rid of those PRs.
I've closed these Compat PRs in batch. We can re-enable CompatHelper (if needed).
I've closed these Compat PRs in batch. We can re-enable CompatHelper (if needed).
As long as the compat entries aren't updated, this would re-open them again next week if I'm not mistaken.
The only real solution here is to update the compat entries, which I'm working on (for example, #248 and #249). My idea was to keep CompatHelper disabled for a bit and first fix the existing backlog of CompatHelper PRs.
The progress of adding assertions can be tracked here: https://github.com/TuringLang/TuringTutorials/issues/218.
CompatHelper is opening too many PRs due to some internal rewrites on their side. Let's disable it for a few months and try to get the already open PRs done. We don't need extra PRs for now.
See also: https://github.com/JuliaRegistries/CompatHelper.jl/issues/378 or other issues at CompatHelper.