Reviewers often find themselves linking to blog posts to encourage newer
devs to improve their commit logs, we can save everyones time by putting
the links in the contributing docs, then we can just point devs there.
These are not run in CI since #2353 and are likely to go out of date. If
we want a script that users can run locally then we should create a new
script that wraps our current CI.
cb42c74f58 policy: Add section on standard set of derives (Tobin C. Harding)
ec1a5a25c7 CONTRIBUTING: Remove stale links (Tobin C. Harding)
Pull request description:
We can have a standard set of derives to make it easier for new devs to work out what to use and also to help us move towards a uniform set in preparation for crate stabilization.
This is not me imposing my view but rather a place for the discussion to happen, could have been a discussions topic also? Using "open" instead of "draft" to aid visibility. Probably requires more than the usual amount of acks.
ACKs for top commit:
apoelstra:
ACK cb42c74f58
Kixunil:
ACK cb42c74f58
Tree-SHA512: b4c4094ea3652e92a5bea90e16f13971202710166524cc15abef5e8318ba5f59df084f5246331870fc641456b49d4e35d266c937375bdc5035f03699a7d4c1b9
We can have a standard set of derives to make it easier for new devs to
work out what to use and also to help us move towards a uniform set in
preparation for crate stabilization. Mention the new `ordered` crate.
3bebecc7ea Add policy section to docs (Tobin C. Harding)
Pull request description:
In an effort to consolidate knowledge spread out over time in various places on GitHub add a `Policy` section to `CONTRIBUTING.md`.
Add initial sections on import statements, errors, rustdocs,attributes, and licensing.
ACKs for top commit:
apoelstra:
ACK 3bebecc7ea
Kixunil:
ACK 3bebecc7ea
Tree-SHA512: fb1afd220a0afae962cd9c7a01df7d440eaa1406b446765af209e3b7840b36aa8a1254d57f9ff0c3783479111470828da3c76b5858ce5969519c96cdba71c7f3
In an effort to consolidate knowledge spread out over time in various
places on GitHub add a `Policy` section to `CONTRIBUTING.md`.
Add initial sections on import statements, errors, rustdocs,attributes,
and licensing.
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`.
Tobin C. Harding
Liam Aharon
Andrew Poelstra
Vojtěch Toman
Einherjar
Martin Habovstiak
Dr Maxim Orlovsky