... | ... | @@ -74,11 +74,13 @@ But we *really appreciate* effort to produce a repro case if you can: |
|
|
```
|
|
|
and thereby avoid the necessity for the supporting library.
|
|
|
|
|
|
If you don't have time to eliminate all dependencies, or if you're unable to do so, **strive to make it possible for us to reproduce your bug**. For example:
|
|
|
* Include version numbers or git commit hashes for each remaining dependency (e.g. via `cabal freeze`)
|
|
|
* Use a tool like `nix` or `docker` to provide a frozen environment in which the bug can be investigated
|
|
|
- **Make your setup as reproducible as possible**. Notably:
|
|
|
* For reproducers which are larger than a few modules in size, it is appreciated if you provide the source in the form of a git repository (or make a branch if the issue is observed in an existing project's repository). This makes it easy for GHC's developers to be certain they have faithfully reproduced your issue.
|
|
|
* If you don't have time to eliminate all dependencies, try to make them reproducible. For example
|
|
|
* Include version numbers or git commit hashes for each remaining dependency (e.g. via `cabal freeze`)
|
|
|
* Use a tool like `nix` or `docker` to provide a frozen environment in which the bug can be investigated
|
|
|
|
|
|
|
|
|
For reproducers which are larger than a few modules in size, it is appreciated if you provide the source in the form of a git repository (or make a branch if the issue is observed in an existing project's repository). This makes it easy for GHC's developers to be certain they have faithfully reproduced your issue.
|
|
|
|
|
|
Lacking this precision makes it difficult to reproduce the problem; we will have to try to guess likely version numbers or commits based on ticket entry dates, which is both painful and unreliable, especially since library maintainers will often add workarounds for the very issues reported here.
|
|
|
|
... | ... | |