From 2675b5fb42b36d6701278f9a7dbf1c507507249b Mon Sep 17 00:00:00 2001 From: Marko Date: Mon, 27 Jul 2020 15:16:48 +0200 Subject: [PATCH] ADR: add missing numbers as blank templates (#5154) ## Description This pr adds missing adr numbers based on what is in #2313 This pr adds empty templates that should later be filled when the time comes to do the implementation. there are still missing numbers, we can either fill them in when we write more ADRs or not backfill numbers and only go forwards. Closes: #2313 --- docs/architecture/README.md | 3 ++ docs/architecture/adr-028-libp2p.md | 38 +++++++++++++++++++ docs/architecture/adr-031-changelog.md | 38 +++++++++++++++++++ .../architecture/adr-036-empty-blocks-abci.md | 38 +++++++++++++++++++ .../adr-038-non-zero-start-height.md | 38 +++++++++++++++++++ 5 files changed, 155 insertions(+) create mode 100644 docs/architecture/adr-028-libp2p.md create mode 100644 docs/architecture/adr-031-changelog.md create mode 100644 docs/architecture/adr-036-empty-blocks-abci.md create mode 100644 docs/architecture/adr-038-non-zero-start-height.md diff --git a/docs/architecture/README.md b/docs/architecture/README.md index ef87fde37..151cb8939 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -55,12 +55,15 @@ Note the context/background should be written in the present tense. - [ADR-024-Sign-Bytes](./adr-024-sign-bytes.md) - [ADR-025-Commit](./adr-025-commit.md) - [ADR-026-General-Merkle-Proof](./adr-026-general-merkle-proof.md) +- [ADR-028-libp2p](./adr-026-libp2p.md) - [ADR-029-Check-Tx-Consensus](./adr-029-check-tx-consensus.md) - [ADR-030-Consensus-Refactor](./adr-030-consensus-refactor.md) +- [ADR-030-Changelog-structure](./adr-031-changelog.md) - [ADR-033-Pubsub](./adr-033-pubsub.md) - [ADR-034-Priv-Validator-File-Structure](./adr-034-priv-validator-file-structure.md) - [ADR-035-Documentation](./adr-035-documentation.md) - [ADR-037-Deliver-Block](./adr-037-deliver-block.md) +- [ADR-038-non-zero-start-height](./adr-038-non-zero-start-height.md) - [ADR-039-Peer-Behaviour](./adr-039-peer-behaviour.md) - [ADR-041-Proposer-Selection-via-ABCI](./adr-041-proposer-selection-via-abci.md) - [ADR-043-Blockchain-RiRi-Org](./adr-043-blockchain-riri-org.md) diff --git a/docs/architecture/adr-028-libp2p.md b/docs/architecture/adr-028-libp2p.md new file mode 100644 index 000000000..fbfe32f12 --- /dev/null +++ b/docs/architecture/adr-028-libp2p.md @@ -0,0 +1,38 @@ +# ADR 028: : LibP2P Integration + +## Changelog + +- {date}: {changelog} + +## Context + +> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. + +## Decision + +> This section explains all of the details of the proposed solution, including implementation details. +> It should also describe affects / corollary items that may need to be changed as a part of this. +> If the proposed change will be large, please also indicate a way to do the change to maximize ease of review. +> (e.g. the optimal split of things to do between separate PR's) + +## Status + +> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement. + +{Deprecated|Proposed|Accepted|Declined} + +## Consequences + +> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. + +### Positive + +### Negative + +### Neutral + +## References + +> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! + +- {reference link} diff --git a/docs/architecture/adr-031-changelog.md b/docs/architecture/adr-031-changelog.md new file mode 100644 index 000000000..56fb875a2 --- /dev/null +++ b/docs/architecture/adr-031-changelog.md @@ -0,0 +1,38 @@ +# ADR 031: Changelog Structure + +## Changelog + +- {date}: {changelog} + +## Context + +> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. + +## Decision + +> This section explains all of the details of the proposed solution, including implementation details. +> It should also describe affects / corollary items that may need to be changed as a part of this. +> If the proposed change will be large, please also indicate a way to do the change to maximize ease of review. +> (e.g. the optimal split of things to do between separate PR's) + +## Status + +> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement. + +{Deprecated|Proposed|Accepted|Declined} + +## Consequences + +> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. + +### Positive + +### Negative + +### Neutral + +## References + +> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! + +- {reference link} diff --git a/docs/architecture/adr-036-empty-blocks-abci.md b/docs/architecture/adr-036-empty-blocks-abci.md new file mode 100644 index 000000000..ec4806cfa --- /dev/null +++ b/docs/architecture/adr-036-empty-blocks-abci.md @@ -0,0 +1,38 @@ +# ADR 036: Empty Blocks via ABCI + +## Changelog + +- {date}: {changelog} + +## Context + +> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. + +## Decision + +> This section explains all of the details of the proposed solution, including implementation details. +> It should also describe affects / corollary items that may need to be changed as a part of this. +> If the proposed change will be large, please also indicate a way to do the change to maximize ease of review. +> (e.g. the optimal split of things to do between separate PR's) + +## Status + +> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement. + +{Deprecated|Proposed|Accepted|Declined} + +## Consequences + +> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. + +### Positive + +### Negative + +### Neutral + +## References + +> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! + +- {reference link} diff --git a/docs/architecture/adr-038-non-zero-start-height.md b/docs/architecture/adr-038-non-zero-start-height.md new file mode 100644 index 000000000..7dd474ec7 --- /dev/null +++ b/docs/architecture/adr-038-non-zero-start-height.md @@ -0,0 +1,38 @@ +# ADR 038: Non-zero start height + +## Changelog + +- {date}: {changelog} + +## Context + +> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. + +## Decision + +> This section explains all of the details of the proposed solution, including implementation details. +> It should also describe affects / corollary items that may need to be changed as a part of this. +> If the proposed change will be large, please also indicate a way to do the change to maximize ease of review. +> (e.g. the optimal split of things to do between separate PR's) + +## Status + +> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement. + +{Deprecated|Proposed|Accepted|Declined} + +## Consequences + +> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. + +### Positive + +### Negative + +### Neutral + +## References + +> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! + +- {reference link}