Merge rust-bitcoin/rust-bitcoin#1945: policy: Add refactor carve out

55be538dac policy: Add refactor carve out (Tobin C. Harding)

Pull request description:

  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, and as such, 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.

  ### Example PRs where this change would apply

  - https://github.com/rust-bitcoin/rust-bitcoin/pull/1925
  - https://github.com/rust-bitcoin/rust-bitcoin/pull/1854
  - https://github.com/rust-bitcoin/rust-bitcoin/pull/1862

ACKs for top commit:
  elichai:
    I agree this makes sense for refactors ACK 55be538dac
  apoelstra:
    ACK 55be538dac
  sanket1729:
    ACK 55be538dac. Same reasons as apoelstra. And this is only for re-factors that are not adding any new features.
  RCasatta:
    ACK 55be538dac

Tree-SHA512: a5e206252015f49245ed282a3be7a35760d16f94dc6e60f31edf589a41ef642eba52a3bd7d1375b6033f3cf0128f47beee4f03e59cad151c64eedd71ac98baac
This commit is contained in:
Andrew Poelstra 2023-08-01 18:16:54 +00:00
commit 1b952def81
No known key found for this signature in database
GPG Key ID: C588D63CE41B97C1
1 changed files with 10 additions and 1 deletions

View File

@ -150,7 +150,7 @@ grammar fixes.
Pull request merge requirements:
- all CI test should pass,
- at least two "accepts"/ACKs from the repository maintainers
- at least two "accepts"/ACKs from the repository maintainers (see "refactor carve out").
- no reasonable "rejects"/NACKs from anybody who reviewed the code.
Current list of the project maintainers:
@ -164,6 +164,15 @@ Current list of the project maintainers:
- [Riccardo Casatta](https://github.com/RCasatta)
- [Tobin Harding](https://github.com/tcharding)
#### Refactor carve output
The repository is going through heavy refactoring and "trivial" API redesign
(eg, rename `Foo::empty` to `Foo::new`) as we push towards API stabilization. As
such reviewers are either bored or overloaded with notifications, hence we have
created a carve out to the 2-ACK rule.
A PR may be considered for merge if it has a single ACK and has sat open for at
least two weeks with no comments, questions, or NACKs.
## Coding conventions