b229fd5555 Use correct form for noun: carve-out (Tobin C. Harding)
Pull request description:
One "carves out" something, not "carve output" - woops.
ACKs for top commit:
apoelstra:
ACK b229fd5555
Tree-SHA512: 196c5c239da35a67b83eb96f2f9346af6518af51ff6bb4a9e40cddab8c8511f2e913278a9727bfe4e97d50c58cb87a4100e40c13c8313643b04a2d0fabaaa9e5
In an effort to reduce review burden add so strict rules defining 3
times where we think it is acceptable for code to be merged with a
single ACK. Feels a bit like we only just added the refactor carve out
and now we are adding more carve outs, so whats next? We should take
these rules seriously, if we are to be taken seriously.
I have managed to burn out or bore our reviewers/maintainers. Getting
two acks is becoming increasingly difficult. I've pestered everyone to
the limit that I feel socially comfortable doing so am requesting a
carve out to the 2-ACK before merge rule.
The primary justification is that I feel we should have a bit more of
BDFL and a bit less total consensus if we are to push forwards.
It could happen that we unknowingly depend on a new version of a crate
without updating `Cargo.toml`. This could cause resolution issues for
downstream users. It's also unclear for outsiders to see which
dependencies we tested the crate with.
This change commits two lock files: `minimal` and `recent`. `minimal`
contains minimal depdendency versions, while `recent` contains
dependency versions at the time of making the change.
Further, this adds CI jobs to test with both lock files, CI job for
`internals` crate, removes old `serde` pinning and prints a warning if
`recent` is no longer up to date. (We may have to override it somehow if
any crate breaks MSRV.)
The documentation is also updated accordingly.
Co-developed-by: Tobin C. Harding <me@tobin.cc>
Closes#1230
b7eea6cb26 Update docs on rustfmt (Tobin C. Harding)
Pull request description:
We have introduced `rustfmt` but forgot to update the docs section about
it. Since a large portion of the codebase is currently ignored by our
`rustfmt` configuration, point out that `rusntfmt` is work in progress.
ACKs for top commit:
apoelstra:
ACK b7eea6cb26
Kixunil:
ACK b7eea6cb26
Tree-SHA512: c3a01e38e9787f7554847c657de8d2aeb512f237f68e97973ffa04e92decd282126abf16edb369c13dbeb9eed3587e20dbfb3ab77e06551a006a7aa2c70a71ad
We have introduced `rustfmt` but forgot to update the docs section about
it. Since a large portion of the codebase is currently ignored by our
`rustfmt` configuration, point out that `rusntfmt` is work in progress.
We have docs that use an env var `BITCOIN_MSRV` that no longer exists.
Point readers towards `RUSTUP_TOOLCHAIN`.
(Note that we still use `TOOLCHAIN` in the script but it is being phased
out, `RUSTUP_TOOLCHAIN` works today.)
We have stale docs referring to the old MSRV. We do not need MSRV docs
in `CONTRIBUTING` because we have them in the README already.
Fix stale docs by doing:
- Remove the MSRV docs from readme in favour of `CONTRIBUTING.md`.
- Add a sentence to the redame pointing readers towards `CONTRIBUTING.md`.
This warns contributors about possible rebases. Changing CONTRIBUTING
should ensure that GitHub will display special warning. This will be
removed after migration is done.
We currently sometimes have one newline before headings and sometimes
two, its not important which it is but uniformity is nice.
Use two newlines before headings uniformly in `CONTRIBUTING.md`.
Vojtěch Toman
Einherjar
Andrew Poelstra
Tobin C. Harding
Martin Habovstiak
Dr Maxim Orlovsky