From 4f2e902271b8d8d5abff34875f4d8b1da8c95285 Mon Sep 17 00:00:00 2001 From: meows Date: Fri, 29 Nov 2019 15:29:06 -0500 Subject: [PATCH 01/25] Init Forking Meta Meta ECIP specification --- _specs/ecip-_.md | 63 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 _specs/ecip-_.md diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md new file mode 100644 index 000000000..6af2169bc --- /dev/null +++ b/_specs/ecip-_.md @@ -0,0 +1,63 @@ +--- +ecip: TBD +title: The Meta Meta ECIP: Processes for Meta ECIPs +author: Mr. Meows D. Bits +discussions-to: TBD +status: WIP +type: Meta +created: 2019-11-29T14:17:42-05:00 +resolution: TBD +--- + +### Abstract + +Forking Meta ECIPs (defined as Meta ECIPs specifying any Standards-Core track ECIP) should be complete and unique. + +### Motivation + +Incomplete proposals are inoperable; they are not ready for implementation. + +Definite proposals are inoperable; they are not ready for implementation. + +Unique proposals saves me time because I don't have to read the same thing twice. + +Related to and derivative of: + +- https://github.com/ethereumclassic/ECIPs/issues/217 +- https://github.com/ethereumclassic/ECIPs/issues/215 +- https://github.com/ethereumclassic/ECIPs/issues/175 +- https://github.com/ethereumclassic/ECIPs/issues/131 +- https://github.com/ethereumclassic/ECIPs/issues/177 +- https://github.com/ethereumclassic/ECIPs/issues/135 +- https://github.com/ethereumclassic/ECIPs/pull/218 +- https://github.com/ethereumclassic/ECIPs/pull/212 +- https://github.com/ethereumclassic/ECIPs/pull/207 +- https://github.com/ethereumclassic/ECIPs/pull/214 +- https://github.com/ethereumclassic/ECIPs/pull/199 +- https://github.com/ethereumclassic/ECIPs/pull/196 + +### Specification + +A hard fork specification is documented as a Meta ECIP, and usually represents a collection of adjacent ECIPs. The sole purpose of a Forking Meta ECIP is to join a block number with this set of `n >= 1` ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." + +This proposal specifies that all Forking Meta ECIPs should be COMPLETE and UNIQUE; essentially disallowing _Draft_ Forking Meta ECIPs and and/or meaningful revisions (set ECIPs, block number). A valid Forking Meta ECIP must contain a full and complete set of to-be included ECIPs, and a definitive block number. + +_Complete_ is defined as being fully and totally definitive; not lacking anything. + +_Unique_ means not the same as another thing; in this case, not precisely duplicating any existing ECIP. + +### Rationale + +0. Forking Meta ECIPs are themselves ECIPs, and their job is to define, with certainty and clarity, technical specifications. Forking Meta ECIPs that essentially leave either field `Block number` and/or field `ECIP set` blank are functionally useless; they say only: "Will have some fork at some time." An analogue of blankness to non-Forking-Meta ECIPs would essentially say "TODO: put my next awesome feature specification here." Fill-in-the-blank ECIPs are not in good form. + +1. A Forking Meta ECIP may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simulateous inclusion. Demanding fully-formed Forking Meta ECIP proposals forces authors to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes. + +2. Concrete ECIPs are easier to reason about. Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. + +### Implementation + +A Forking Meta ECIP may not be in `Draft` status. It may not undergo any meaningful changes once receiving `Last Call` status (its next status beyond `WIP`). + +### Copyright/Licensing + +MIT. From 18ba1dd84b1199180ef74f7fee27d6660f88a76e Mon Sep 17 00:00:00 2001 From: meows Date: Fri, 29 Nov 2019 15:31:12 -0500 Subject: [PATCH 02/25] Improve language around status adjectives --- _specs/ecip-_.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index 6af2169bc..b6b6e55a0 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -40,7 +40,7 @@ Related to and derivative of: A hard fork specification is documented as a Meta ECIP, and usually represents a collection of adjacent ECIPs. The sole purpose of a Forking Meta ECIP is to join a block number with this set of `n >= 1` ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." -This proposal specifies that all Forking Meta ECIPs should be COMPLETE and UNIQUE; essentially disallowing _Draft_ Forking Meta ECIPs and and/or meaningful revisions (set ECIPs, block number). A valid Forking Meta ECIP must contain a full and complete set of to-be included ECIPs, and a definitive block number. +This proposal specifies that all Forking Meta ECIPs should be COMPLETE and UNIQUE; essentially disallowing `Draft` status Forking Meta ECIPs and and/or meaningful revisions (set ECIPs, block number). A valid Forking Meta ECIP must contain a full and complete set of to-be included ECIPs, and a definitive block number. _Complete_ is defined as being fully and totally definitive; not lacking anything. From abf98b0dd476767c2420dad259d5544c0d430927 Mon Sep 17 00:00:00 2001 From: meows Date: Fri, 29 Nov 2019 15:35:16 -0500 Subject: [PATCH 03/25] Add rationale section specifically for block number spec --- _specs/ecip-_.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index b6b6e55a0..da4a181c5 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -52,7 +52,9 @@ _Unique_ means not the same as another thing; in this case, not precisely duplic 1. A Forking Meta ECIP may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simulateous inclusion. Demanding fully-formed Forking Meta ECIP proposals forces authors to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes. -2. Concrete ECIPs are easier to reason about. Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. +2. Forking Meta ECIPs without block numbers lack operability. Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in independence. + +3. Concrete ECIPs are easier to reason about. Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. ### Implementation From 76872bde3b069d03225da2de3af62bb5231fdcaf Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 07:33:29 -0500 Subject: [PATCH 04/25] Fix typo (remove rough draft 'definitive' concept vestige) --- _specs/ecip-_.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index da4a181c5..8c1f891d2 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -17,8 +17,6 @@ Forking Meta ECIPs (defined as Meta ECIPs specifying any Standards-Core track EC Incomplete proposals are inoperable; they are not ready for implementation. -Definite proposals are inoperable; they are not ready for implementation. - Unique proposals saves me time because I don't have to read the same thing twice. Related to and derivative of: From bbf1c2f1a8400c50e7f15127844122ab11e7ff76 Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 07:38:41 -0500 Subject: [PATCH 05/25] Fix typos --- _specs/ecip-_.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index 8c1f891d2..389ca1cd6 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -48,9 +48,9 @@ _Unique_ means not the same as another thing; in this case, not precisely duplic 0. Forking Meta ECIPs are themselves ECIPs, and their job is to define, with certainty and clarity, technical specifications. Forking Meta ECIPs that essentially leave either field `Block number` and/or field `ECIP set` blank are functionally useless; they say only: "Will have some fork at some time." An analogue of blankness to non-Forking-Meta ECIPs would essentially say "TODO: put my next awesome feature specification here." Fill-in-the-blank ECIPs are not in good form. -1. A Forking Meta ECIP may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simulateous inclusion. Demanding fully-formed Forking Meta ECIP proposals forces authors to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes. +1. A Forking Meta ECIP may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. Demanding fully-formed Forking Meta ECIP proposals forces authors to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes. -2. Forking Meta ECIPs without block numbers lack operability. Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in independence. +2. Forking Meta ECIPs without block numbers lack operability. Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation. 3. Concrete ECIPs are easier to reason about. Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. From 164c68c513aa453a30de34a79d3e6c4a0f55b1ac Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 14:26:56 -0500 Subject: [PATCH 06/25] Write a little more --- _specs/ecip-_.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index 389ca1cd6..df8fbf750 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -15,9 +15,9 @@ Forking Meta ECIPs (defined as Meta ECIPs specifying any Standards-Core track EC ### Motivation -Incomplete proposals are inoperable; they are not ready for implementation. +Incomplete proposals are inoperable; they are not ready for review, discussion, nor implementation. -Unique proposals saves me time because I don't have to read the same thing twice. +Unique proposals save time and redundant complexity. Related to and derivative of: @@ -36,28 +36,34 @@ Related to and derivative of: ### Specification -A hard fork specification is documented as a Meta ECIP, and usually represents a collection of adjacent ECIPs. The sole purpose of a Forking Meta ECIP is to join a block number with this set of `n >= 1` ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." - -This proposal specifies that all Forking Meta ECIPs should be COMPLETE and UNIQUE; essentially disallowing `Draft` status Forking Meta ECIPs and and/or meaningful revisions (set ECIPs, block number). A valid Forking Meta ECIP must contain a full and complete set of to-be included ECIPs, and a definitive block number. +A Forking Meta ECIP is defined as a Meta ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set. A Forking Meta ECIP should be complete and unique. _Complete_ is defined as being fully and totally definitive; not lacking anything. _Unique_ means not the same as another thing; in this case, not precisely duplicating any existing ECIP. +This proposal specifies that all Forking Meta ECIPs should be COMPLETE and UNIQUE; essentially disallowing `Draft` status Forking Meta ECIPs and and/or meaningful revisions (set ECIPs, block number). + +This implies that a valid Forking Meta ECIP must contain a full and complete set of to-be included ECIPs, and a definitive block number. + ### Rationale -0. Forking Meta ECIPs are themselves ECIPs, and their job is to define, with certainty and clarity, technical specifications. Forking Meta ECIPs that essentially leave either field `Block number` and/or field `ECIP set` blank are functionally useless; they say only: "Will have some fork at some time." An analogue of blankness to non-Forking-Meta ECIPs would essentially say "TODO: put my next awesome feature specification here." Fill-in-the-blank ECIPs are not in good form. +The sole purpose of a Forking Meta ECIP is to join a block number with a set of `n >= 1` ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." -1. A Forking Meta ECIP may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. Demanding fully-formed Forking Meta ECIP proposals forces authors to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes. +0. __Fill-in-the-blank ECIPs are not in good form.__ Forking Meta ECIPs are themselves ECIPs, and their job is to define, with certainty and clarity, technical specifications. Forking Meta ECIPs that essentially leave either field `Block number` and/or field `ECIP set` blank are functionally useless (inoperable); they say only: "(I/we) propose to have some fork at some time." An analogue of blankness to non-Forking-Meta ECIPs would essentially say "TODO: put my next awesome feature specification here." -2. Forking Meta ECIPs without block numbers lack operability. Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation. +1. __Demanding fully-formed Forking Meta ECIP proposals forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Forking Meta ECIP may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. -3. Concrete ECIPs are easier to reason about. Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. +2. __Forking Meta ECIPs without block numbers lack operability.__ Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation. + +3. __Concrete ECIPs are easier to build language and reasoning around.__ Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. "Competing" Forking Meta ECIP alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes. ### Implementation A Forking Meta ECIP may not be in `Draft` status. It may not undergo any meaningful changes once receiving `Last Call` status (its next status beyond `WIP`). +Procedurally, compared to the historical and traditional practice of opening an essentially empty Forking Meta ECIP and working to fill in blanks, this proposed procedure makes only marginal and changes, demanding only that what was taken as implication, subtext, or conteext before now be made explicit. Rather than reviewing actual-or-theoretical proposed change sets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration. + ### Copyright/Licensing MIT. From bfd3a9c8f876b59c80c82eab5435ab0e0cf60e87 Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 14:33:21 -0500 Subject: [PATCH 07/25] Fix Forking Meta ECIP spec to include must have activation block number --- _specs/ecip-_.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index df8fbf750..c0466fa61 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -11,7 +11,7 @@ resolution: TBD ### Abstract -Forking Meta ECIPs (defined as Meta ECIPs specifying any Standards-Core track ECIP) should be complete and unique. +Forking Meta ECIPs (defined as Meta ECIPs specifying any Standards-Core track ECIP and an activation block number) should be complete and unique. ### Motivation From 4ef35f941384942ead39e6bff52a4cce0e1d0e3e Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 15:11:39 -0500 Subject: [PATCH 08/25] Introduce alternative approach; use PRs --- _specs/ecip-_.md | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index c0466fa61..a45642907 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -11,11 +11,23 @@ resolution: TBD ### Abstract -Forking Meta ECIPs (defined as Meta ECIPs specifying any Standards-Core track ECIP and an activation block number) should be complete and unique. +Forking Meta ECIPs (defined as Meta ECIPs _intended_ to specify any Standards-Core track ECIP and an activation block number) should contain only placeholder information +for ECIP-sets and block activation numbers. Placeholders for ECIP-sets and block numbers should be filled via distinct change sets before moving from `Draft` to `Last Call` status. + +Changesets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither in isolation; PRs modifying only ECIP-set, or only block number, +are disallowed. ### Motivation -Incomplete proposals are inoperable; they are not ready for review, discussion, nor implementation. +Allowing fully-formed alternative and "competing" ECIPs is logistically and practically difficult to use. Currently, our most prominently used collaboration tool, Github, does +not provide an accessible UI for comparing arbitrary documents or review separate arbitrary documents as a conceptual set. + +Github does, however, provide an accessible user interface for Pull Requests (propsed change sets) against a single document. + +Forking Meta ECIPs represent a single idea: The next hardfork. This is a pragramtic and common sense approach to managing blockchain protocol maintenance and upgrades. Thus, it makes +sense to use accessible and conceptually-unifying procedures for this challenge. + +Incomplete proposals (changesets) are inoperable; they are not ready for review, discussion, nor implementation. Unique proposals save time and redundant complexity. @@ -36,33 +48,31 @@ Related to and derivative of: ### Specification -A Forking Meta ECIP is defined as a Meta ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set. A Forking Meta ECIP should be complete and unique. +A Forking Meta ECIP is defined as a Meta ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set. A Forking Meta ECIP should be conceptally complete and unique (_next hardfork_ suffices for uniqueness, since there can only be one). _Complete_ is defined as being fully and totally definitive; not lacking anything. _Unique_ means not the same as another thing; in this case, not precisely duplicating any existing ECIP. -This proposal specifies that all Forking Meta ECIPs should be COMPLETE and UNIQUE; essentially disallowing `Draft` status Forking Meta ECIPs and and/or meaningful revisions (set ECIPs, block number). - -This implies that a valid Forking Meta ECIP must contain a full and complete set of to-be included ECIPs, and a definitive block number. +This proposal specifies that all Forking Meta ECIPs in `Draft` state or earlier should contain NO information about ECIP-sets or block activation numbers (all `TBD`). Proposed specifications to fill these placeholders should be made in the form of distinct and separate propsed change sets (eg Github Pull Requests) to the Forking Meta ECIP document. The changesets are required to be UNIQUE and COMPLETE. ### Rationale The sole purpose of a Forking Meta ECIP is to join a block number with a set of `n >= 1` ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." -0. __Fill-in-the-blank ECIPs are not in good form.__ Forking Meta ECIPs are themselves ECIPs, and their job is to define, with certainty and clarity, technical specifications. Forking Meta ECIPs that essentially leave either field `Block number` and/or field `ECIP set` blank are functionally useless (inoperable); they say only: "(I/we) propose to have some fork at some time." An analogue of blankness to non-Forking-Meta ECIPs would essentially say "TODO: put my next awesome feature specification here." +0. "Shell" format Forking Meta ECIPs represent a clear, albeit abstract, idea: The blockchain's next hard fork. -1. __Demanding fully-formed Forking Meta ECIP proposals forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Forking Meta ECIP may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. +1. __Demanding fully-formed Forking Meta ECIP Changeset proposal forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Forking Meta ECIP Changeset may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. -2. __Forking Meta ECIPs without block numbers lack operability.__ Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation. +2. __Forking Meta ECIP Changesets without block numbers lack operability.__ Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation. -3. __Concrete ECIPs are easier to build language and reasoning around.__ Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. "Competing" Forking Meta ECIP alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes. +3. __Concrete things are easier to build language and reasoning around.__ Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. "Competing" Forking Meta ECIP Changeset alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes. ### Implementation -A Forking Meta ECIP may not be in `Draft` status. It may not undergo any meaningful changes once receiving `Last Call` status (its next status beyond `WIP`). +A Forking Meta ECIP may only achieve `Last Call` status once a Changeset has been accepted and all other alternative marked as `Deferred`, `Withdrawn`, or `Rejected`. -Procedurally, compared to the historical and traditional practice of opening an essentially empty Forking Meta ECIP and working to fill in blanks, this proposed procedure makes only marginal and changes, demanding only that what was taken as implication, subtext, or conteext before now be made explicit. Rather than reviewing actual-or-theoretical proposed change sets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration. +This proposed procedure makes only marginal and changes, demanding only that what was taken as implication, subtext, or conteext before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration. ### Copyright/Licensing From cf85164c0c34f785b03badc78ab2d72ce4fd323e Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 16:19:10 -0500 Subject: [PATCH 09/25] Fix typo --- _specs/ecip-_.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index a45642907..fa978bb56 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -72,7 +72,7 @@ The sole purpose of a Forking Meta ECIP is to join a block number with a set of A Forking Meta ECIP may only achieve `Last Call` status once a Changeset has been accepted and all other alternative marked as `Deferred`, `Withdrawn`, or `Rejected`. -This proposed procedure makes only marginal and changes, demanding only that what was taken as implication, subtext, or conteext before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration. +This proposed procedure makes only marginal and changes, demanding only that what was taken as implication, subtext, or context before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration. ### Copyright/Licensing From 93895296e4c969f07f99b304db1569a573268892 Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 17:15:13 -0500 Subject: [PATCH 10/25] Establish specification and process standards for Fork type ECIPs --- _specs/ecip-1000.md | 5 ++-- _specs/ecip-_.md | 66 ++++++++++++++++++++++++++++++--------------- 2 files changed, 48 insertions(+), 23 deletions(-) diff --git a/_specs/ecip-1000.md b/_specs/ecip-1000.md index b5b50dd36..97bb21840 100644 --- a/_specs/ecip-1000.md +++ b/_specs/ecip-1000.md @@ -131,7 +131,7 @@ Each ECIP must begin with an RFC 822 style header preamble. The headers must app - **Comments-Summary:** (summary tone) - **Comments-URI:** (links to wiki page for comments) - **Status:** (Draft | Last Call | Accepted | Final | Deferred | Replaced | Rejected | Withdrawn) -- **Type:** (Standards Track | Informational | Process) +- **Type:** (Standards Track | Informational | Meta | Fork) - **Created:** (date created on, in ISO 8601 (yyyy-mm-dd) format) - **License:** (abbreviation for approved license(s)) - **License-Code:** (abbreviation for code under different approved license(s)) @@ -150,7 +150,7 @@ If there are multiple authors, each should be on a separate line following RFC 2 While an ECIP is in private discussions (usually during the initial Draft phase), a`Discussions-To` header will indicate the mailing list or URL where the ECIP is being discussed. No `Discussions-To` header is necessary if the ECIP is being discussed privately with the author. -The `Type` header specifies the type of ECIP: Standards Track, Informational, or Process. +The `Type` header specifies the type of ECIP: Standards Track, Informational, Meta, Fork. The `Created` header records the date that the ECIP was assigned a number. @@ -172,6 +172,7 @@ There are three types of ECIP: - **Interface** - improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names and contract ABIs. - **ECBP (Ethereum Classic Best Practice)** - application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats. - A **Meta ECIP** describes a **process** surrounding Ethereum Classic or proposes a change to (or an event in) a process. Process ECIPs are like Standard Track ECIPs, but apply to areas other than the Ethereum Classic protocol itself. They may propose an implementation, but not to Ethereum Classic's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process (e.g. this ECIP-1000 process document), and changes to the tools or environment used in Ethereum Classic development. *Any meta-ECIP is also considered a Process ECIP.* +- A **Fork ECIP** describes a feature set and a block activation number for those features to become active on one or more blockchains. - An **Informational ECIP** describes an Ethereum Classic design issue, or provides general guidelines or information to the Ethereum Classic community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum Classic community consensus or a recommendation, so users and implementors are free to ignore Informational ECIPs or follow their advice. It is highly recommended that a single ECIP contain a single key proposal or new idea. The more focused the ECIP, the more successful it tends to be. A change to one client doesn't require an ECIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does. diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index fa978bb56..8a3a7e821 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -1,6 +1,6 @@ --- ecip: TBD -title: The Meta Meta ECIP: Processes for Meta ECIPs +title: The Meta Fork ECIP: Establishing _Fork_ type ECIPs and their specifications and processes author: Mr. Meows D. Bits discussions-to: TBD status: WIP @@ -11,25 +11,42 @@ resolution: TBD ### Abstract -Forking Meta ECIPs (defined as Meta ECIPs _intended_ to specify any Standards-Core track ECIP and an activation block number) should contain only placeholder information -for ECIP-sets and block activation numbers. Placeholders for ECIP-sets and block numbers should be filled via distinct change sets before moving from `Draft` to `Last Call` status. +Establishing _Fork_ type ECIPs, and their standards and processes. -Changesets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither in isolation; PRs modifying only ECIP-set, or only block number, -are disallowed. +#### TL;DR + +Make ECIPs with `Type` _Fork_ a thing. _Fork_ ECIPs should follow this process: +- A "shell" Fork ECIP is opened, fitting the [template provided](TODO). This ECIP __does not initially include `Activation Block Number` or `Features` specifications__. +- While in `WIP` or `Draft` status, one or more change sets are proposed against this document (eg. via Github Pull Requests) __modifying BOTH `Activation Block Number` and `Features` specifications__. +- ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive criticiziing, etc... +- One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document. + +### Definition + +Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or more Standards-Core track ECIP(s) at a specified activation block number. + +#### Standards + +Fork ECIPs should contain only placeholder information for ECIP-sets and block activation numbers while in `WIP` or `Draft` status. + +Modification to any of `Last Call`, `Accepted`, `Final`, or `Active` statuses should be accompanied by the introduction (merge) of a single change set containing COMPLETE and UNIQUE definitions of the placeholder values. + +Change sets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither value in isolation; change sets modifying only ECIP-set values, or only block number values, are disallowed. ### Motivation -Allowing fully-formed alternative and "competing" ECIPs is logistically and practically difficult to use. Currently, our most prominently used collaboration tool, Github, does -not provide an accessible UI for comparing arbitrary documents or review separate arbitrary documents as a conceptual set. +Fork ECIPs represent a single idea: The next hardfork the blockchain is expected to undergo. This is a pragmatic and common approach to managing blockchain protocol maintenance and upgrades. +Thus, it makes sense to use accessible and conceptually-unifying procedures for this challenge. + +- __Accessibility__: Github provides an accessible user interface for viewing a Pull Request (proposed change set) against a single document. -Github does, however, provide an accessible user interface for Pull Requests (propsed change sets) against a single document. +- __Legible and Communicable Reasoning__: Requiring UNIQUE and COMPLETE change sets against against a Fork type ECIP demand presentation and consideration of proposed specifications as a whole. -Forking Meta ECIPs represent a single idea: The next hardfork. This is a pragramtic and common sense approach to managing blockchain protocol maintenance and upgrades. Thus, it makes -sense to use accessible and conceptually-unifying procedures for this challenge. +- __Sufficient specification__: It is the job of Fork ECIPs to eventually provide precise and operable implementation specifications. Incomplete proposals (changesets) are inoperable; they are not ready for review, discussion, nor implementation. Any Fork ECIP lacking a COMPLETE feature set or block number is considered incomplete. -Incomplete proposals (changesets) are inoperable; they are not ready for review, discussion, nor implementation. +- __Efficiency__: Unique proposals save time and energy. -Unique proposals save time and redundant complexity. +#### Historical motivations Related to and derivative of: @@ -48,31 +65,38 @@ Related to and derivative of: ### Specification -A Forking Meta ECIP is defined as a Meta ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set. A Forking Meta ECIP should be conceptally complete and unique (_next hardfork_ suffices for uniqueness, since there can only be one). +A Fork ECIP is defined as an ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set and a block activation number for this set. A Fork ECIP should be conceptually complete and unique (note that _Next hardfork_ suffices for the existing preference for ECIP uniqueness, since it is intended that there only be one at a time -- hopefully!). _Complete_ is defined as being fully and totally definitive; not lacking anything. _Unique_ means not the same as another thing; in this case, not precisely duplicating any existing ECIP. -This proposal specifies that all Forking Meta ECIPs in `Draft` state or earlier should contain NO information about ECIP-sets or block activation numbers (all `TBD`). Proposed specifications to fill these placeholders should be made in the form of distinct and separate propsed change sets (eg Github Pull Requests) to the Forking Meta ECIP document. The changesets are required to be UNIQUE and COMPLETE. +This proposal specifies that all Fork ECIPs in `Draft` state or earlier should contain NO information about ECIP-sets or block activation numbers (all `TBD`). Proposed specifications to fill these placeholders should be made in the form of distinct and separate propsed change sets (eg Github Pull Requests) to the Fork ECIP document. The changesets are required to be UNIQUE and COMPLETE. ### Rationale -The sole purpose of a Forking Meta ECIP is to join a block number with a set of `n >= 1` ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." +The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of `n >= 1` Standards-Core type ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." + +0. "Shell" format Fork ECIPs represent a clear, albeit abstract, idea: The blockchain's next hard fork. + +1. __Demanding fully-formed Fork ECIP Changeset proposal forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Fork ECIP Changeset may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. The intention of this specification is make these logical steps as explicit and document and accessible as possible, in order that good decisions can be made with a process of open and constructive collaboration, enabled by named and concrete options. + +2. __Fork ECIP Changesets without block numbers lack operability.__ Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation. -0. "Shell" format Forking Meta ECIPs represent a clear, albeit abstract, idea: The blockchain's next hard fork. +3. __Concrete things are easier to build language and reasoning around.__ Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. "Competing" Fork ECIP Changeset alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes. -1. __Demanding fully-formed Forking Meta ECIP Changeset proposal forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Forking Meta ECIP Changeset may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. +#### Alternatives considered -2. __Forking Meta ECIP Changesets without block numbers lack operability.__ Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation. +Use distinct UNIQUE and COMPLETE ECIPs to describe fork specification options. -3. __Concrete things are easier to build language and reasoning around.__ Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. "Competing" Forking Meta ECIP Changeset alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes. +However, allowing fully-formed alternative and "competing" ECIPs is logistically and practically difficult to use. +Currently, our most prominently used collaboration tool, Github, does not provide an accessible UI for comparing arbitrary documents or review separate arbitrary documents as a conceptual set. ### Implementation -A Forking Meta ECIP may only achieve `Last Call` status once a Changeset has been accepted and all other alternative marked as `Deferred`, `Withdrawn`, or `Rejected`. +A Fork ECIP should achieve `Last Call` as a change set has been successfully merged. Conversely, a Fork ECIP with non-empty specifications may not see `Draft` or `WIP` status; it may only otherwise `Active`, `Withdrawn`, or `Rejected`. -This proposed procedure makes only marginal and changes, demanding only that what was taken as implication, subtext, or context before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration. +This proposed procedure makes only marginal conceptual changes to existing practices, demanding only that what was taken as implication, subtext, or context before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Fork ECIP specification outcomes to assume fully qualified and standardized formats before becoming eligible for consideration. ### Copyright/Licensing From 6e9b361c2af084af9fcee9089cbad538b21e41d8 Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 17:24:40 -0500 Subject: [PATCH 11/25] Use assigned ECIP number 1077 Resolved conflicts: Conflicts: _specs/ecip-_.md --- _specs/ecip-_.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-_.md b/_specs/ecip-_.md index 8a3a7e821..10db9e9cf 100644 --- a/_specs/ecip-_.md +++ b/_specs/ecip-_.md @@ -1,5 +1,5 @@ --- -ecip: TBD +ecip: 1077 title: The Meta Fork ECIP: Establishing _Fork_ type ECIPs and their specifications and processes author: Mr. Meows D. Bits discussions-to: TBD From 2b576ccd751b7bfdd2606df153d68361e9186df7 Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 17:25:27 -0500 Subject: [PATCH 12/25] Rename ECIP file to reflect assigned number (1077) --- _specs/{ecip-_.md => ecip-1077.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename _specs/{ecip-_.md => ecip-1077.md} (100%) diff --git a/_specs/ecip-_.md b/_specs/ecip-1077.md similarity index 100% rename from _specs/ecip-_.md rename to _specs/ecip-1077.md From b9478e610fdf1ae082ec32c0d9d4408ff5ced481 Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 17:32:47 -0500 Subject: [PATCH 13/25] Add link to Fork-type specification ECIP Resolves https://github.com/ethereumclassic/ECIPs/pull/224#discussion_r352307638 --- _specs/ecip-1000.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-1000.md b/_specs/ecip-1000.md index 97bb21840..57d8ca702 100644 --- a/_specs/ecip-1000.md +++ b/_specs/ecip-1000.md @@ -172,7 +172,7 @@ There are three types of ECIP: - **Interface** - improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names and contract ABIs. - **ECBP (Ethereum Classic Best Practice)** - application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats. - A **Meta ECIP** describes a **process** surrounding Ethereum Classic or proposes a change to (or an event in) a process. Process ECIPs are like Standard Track ECIPs, but apply to areas other than the Ethereum Classic protocol itself. They may propose an implementation, but not to Ethereum Classic's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process (e.g. this ECIP-1000 process document), and changes to the tools or environment used in Ethereum Classic development. *Any meta-ECIP is also considered a Process ECIP.* -- A **Fork ECIP** describes a feature set and a block activation number for those features to become active on one or more blockchains. +- A **Fork ECIP** describes a feature set and a block activation number for those features to become active on one or more blockchains. For specification and process standards, see [ECIP 1077](./_specs/ecip-1077.md). - An **Informational ECIP** describes an Ethereum Classic design issue, or provides general guidelines or information to the Ethereum Classic community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum Classic community consensus or a recommendation, so users and implementors are free to ignore Informational ECIPs or follow their advice. It is highly recommended that a single ECIP contain a single key proposal or new idea. The more focused the ECIP, the more successful it tends to be. A change to one client doesn't require an ECIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does. From 2c40819dc9f480632a74f267e9bb828dd47657aa Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 17:34:13 -0500 Subject: [PATCH 14/25] Set date metadata to day granularity --- _specs/ecip-1077.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index 10db9e9cf..b31ba9736 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -5,7 +5,7 @@ author: Mr. Meows D. Bits discussions-to: TBD status: WIP type: Meta -created: 2019-11-29T14:17:42-05:00 +created: 2019-11-29 resolution: TBD --- From aaf75959895341c82e900081f35611886d055fe9 Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 17:35:09 -0500 Subject: [PATCH 15/25] Remove metadata field Resolution It was vestigial from ECIP template. Not sure what it's for. Seem irrelevant here. --- _specs/ecip-1077.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index b31ba9736..7415ad85c 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -6,7 +6,6 @@ discussions-to: TBD status: WIP type: Meta created: 2019-11-29 -resolution: TBD --- ### Abstract From b00bdcacc07bae5436a1444f2c781c8f49508fce Mon Sep 17 00:00:00 2001 From: meows Date: Sat, 30 Nov 2019 17:37:34 -0500 Subject: [PATCH 16/25] Remove allowance for Active status for Fork type ECIPs Once Accepted, Fork specifications should never change. The status Final is sufficient to describe this state. Resolves https://github.com/ethereumclassic/ECIPs/pull/224#discussion_r352307777 --- _specs/ecip-1077.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index 7415ad85c..9068f16f4 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -28,7 +28,7 @@ Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or mor Fork ECIPs should contain only placeholder information for ECIP-sets and block activation numbers while in `WIP` or `Draft` status. -Modification to any of `Last Call`, `Accepted`, `Final`, or `Active` statuses should be accompanied by the introduction (merge) of a single change set containing COMPLETE and UNIQUE definitions of the placeholder values. +Modification to any of `Last Call`, `Accepted`, or `Final` statuses should be accompanied by the introduction (merge) of a single change set containing COMPLETE and UNIQUE definitions of the placeholder values. Change sets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither value in isolation; change sets modifying only ECIP-set values, or only block number values, are disallowed. @@ -93,7 +93,7 @@ Currently, our most prominently used collaboration tool, Github, does not provid ### Implementation -A Fork ECIP should achieve `Last Call` as a change set has been successfully merged. Conversely, a Fork ECIP with non-empty specifications may not see `Draft` or `WIP` status; it may only otherwise `Active`, `Withdrawn`, or `Rejected`. +A Fork ECIP should achieve `Last Call` as a change set has been successfully merged. Conversely, a Fork ECIP with non-empty specifications may not see `Draft` or `WIP` status; it may only otherwise be `Final`, `Withdrawn`, or `Rejected`. This proposed procedure makes only marginal conceptual changes to existing practices, demanding only that what was taken as implication, subtext, or context before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Fork ECIP specification outcomes to assume fully qualified and standardized formats before becoming eligible for consideration. From 33a7c56f818617b7d083a8e29fba4d144adfb717 Mon Sep 17 00:00:00 2001 From: meows Date: Sun, 1 Dec 2019 07:52:36 -0500 Subject: [PATCH 17/25] Update TLDR section --- _specs/ecip-1077.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index 9068f16f4..20355fb19 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -14,11 +14,11 @@ Establishing _Fork_ type ECIPs, and their standards and processes. #### TL;DR -Make ECIPs with `Type` _Fork_ a thing. _Fork_ ECIPs should follow this process: +Make ECIPs with `Type` _Fork_ a thing, where _Fork_ ECIPs should follow this process: - A "shell" Fork ECIP is opened, fitting the [template provided](TODO). This ECIP __does not initially include `Activation Block Number` or `Features` specifications__. - While in `WIP` or `Draft` status, one or more change sets are proposed against this document (eg. via Github Pull Requests) __modifying BOTH `Activation Block Number` and `Features` specifications__. - ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive criticiziing, etc... -- One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document. +- One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document, and status is moved to `Last Call`. By virtue of the process specification provided, a Fork ECIP achieving `Last Call` may not see `Draft` nor `WIP` status again (because doing so would require a merging a change set holding INCOMPLETE specification variables). ### Definition From a5fcfa924bdd70d83dfb8d1129b58a65a2ecc67d Mon Sep 17 00:00:00 2001 From: meows Date: Sun, 1 Dec 2019 07:53:28 -0500 Subject: [PATCH 18/25] Fix typo --- _specs/ecip-1077.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index 20355fb19..6258b4288 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -17,7 +17,7 @@ Establishing _Fork_ type ECIPs, and their standards and processes. Make ECIPs with `Type` _Fork_ a thing, where _Fork_ ECIPs should follow this process: - A "shell" Fork ECIP is opened, fitting the [template provided](TODO). This ECIP __does not initially include `Activation Block Number` or `Features` specifications__. - While in `WIP` or `Draft` status, one or more change sets are proposed against this document (eg. via Github Pull Requests) __modifying BOTH `Activation Block Number` and `Features` specifications__. -- ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive criticiziing, etc... +- ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive critique, etc... - One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document, and status is moved to `Last Call`. By virtue of the process specification provided, a Fork ECIP achieving `Last Call` may not see `Draft` nor `WIP` status again (because doing so would require a merging a change set holding INCOMPLETE specification variables). ### Definition From 68b82f40a52c68cac20c71319193635a4e385f6b Mon Sep 17 00:00:00 2001 From: meows Date: Sun, 1 Dec 2019 08:47:46 -0500 Subject: [PATCH 19/25] Add Fork type ECIP template --- _specs/ecip-1077.md | 2 +- ecip-X-FORK.md | 36 ++++++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 ecip-X-FORK.md diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index 6258b4288..fd8903d45 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -15,7 +15,7 @@ Establishing _Fork_ type ECIPs, and their standards and processes. #### TL;DR Make ECIPs with `Type` _Fork_ a thing, where _Fork_ ECIPs should follow this process: -- A "shell" Fork ECIP is opened, fitting the [template provided](TODO). This ECIP __does not initially include `Activation Block Number` or `Features` specifications__. +- A "shell" Fork ECIP is opened, fitting the [template provided named `ecip-X-FORK.md`](ecip-X-FORK.md) (available in the repository root directory). This ECIP __does not initially include `Activation Block Number` or `Features` specifications__. - While in `WIP` or `Draft` status, one or more change sets are proposed against this document (eg. via Github Pull Requests) __modifying BOTH `Activation Block Number` and `Features` specifications__. - ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive critique, etc... - One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document, and status is moved to `Last Call`. By virtue of the process specification provided, a Fork ECIP achieving `Last Call` may not see `Draft` nor `WIP` status again (because doing so would require a merging a change set holding INCOMPLETE specification variables). diff --git a/ecip-X-FORK.md b/ecip-X-FORK.md new file mode 100644 index 000000000..86cc33b22 --- /dev/null +++ b/ecip-X-FORK.md @@ -0,0 +1,36 @@ +--- +ecip: +title: +author: +discussions-to: +status: +type: Fork +created: +replaces: +superseded-by: +resolution: +--- + +### Abstract + +Specifying a next hardfork for the following networks: + +- +- + +### Motivation + +### Specification + +- __Block Activation Number(s)__: + + : `TBD` + + : `TBD` + +- __Feature specification(s)__: + + TBD + +### Rationale + +### Implementation + +### Copyright/Licensing From e2ba04426e27d487eaf3f6a7f58cdf8b8b98f97f Mon Sep 17 00:00:00 2001 From: meows Date: Sun, 1 Dec 2019 08:48:44 -0500 Subject: [PATCH 20/25] Fix template link --- _specs/ecip-1077.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index fd8903d45..14b7072b5 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -15,7 +15,7 @@ Establishing _Fork_ type ECIPs, and their standards and processes. #### TL;DR Make ECIPs with `Type` _Fork_ a thing, where _Fork_ ECIPs should follow this process: -- A "shell" Fork ECIP is opened, fitting the [template provided named `ecip-X-FORK.md`](ecip-X-FORK.md) (available in the repository root directory). This ECIP __does not initially include `Activation Block Number` or `Features` specifications__. +- A "shell" Fork ECIP is opened, fitting the [template provided named `ecip-X-FORK.md`](../ecip-X-FORK.md) (available in the repository root directory). This ECIP __does not initially include `Activation Block Number` or `Features` specifications__. - While in `WIP` or `Draft` status, one or more change sets are proposed against this document (eg. via Github Pull Requests) __modifying BOTH `Activation Block Number` and `Features` specifications__. - ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive critique, etc... - One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document, and status is moved to `Last Call`. By virtue of the process specification provided, a Fork ECIP achieving `Last Call` may not see `Draft` nor `WIP` status again (because doing so would require a merging a change set holding INCOMPLETE specification variables). From 1b3641be848aa878877e9f0263ffdb67af936b80 Mon Sep 17 00:00:00 2001 From: meows Date: Sun, 1 Dec 2019 08:52:46 -0500 Subject: [PATCH 21/25] Use 'IP' instead of 'ECIP' This allows protocol upgrade specifications to be derived and/or defined in any IP (Improvement Proposal) context, include ECIP, EIP, BIP, etc. --- _specs/ecip-1077.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index 14b7072b5..d526bd72d 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -22,7 +22,7 @@ Make ECIPs with `Type` _Fork_ a thing, where _Fork_ ECIPs should follow this pro ### Definition -Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or more Standards-Core track ECIP(s) at a specified activation block number. +Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or more Standards-Core track IP(s) at a specified activation block number. #### Standards @@ -64,7 +64,7 @@ Related to and derivative of: ### Specification -A Fork ECIP is defined as an ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set and a block activation number for this set. A Fork ECIP should be conceptually complete and unique (note that _Next hardfork_ suffices for the existing preference for ECIP uniqueness, since it is intended that there only be one at a time -- hopefully!). +A Fork ECIP is defined as an ECIP specifying any (`n >= 1`) Standards-Core track IP or IP-set and a block activation number for this set. A Fork ECIP should be conceptually complete and unique (note that _Next hardfork_ suffices for the existing preference for ECIP uniqueness, since it is intended that there only be one at a time -- hopefully!). _Complete_ is defined as being fully and totally definitive; not lacking anything. @@ -74,7 +74,7 @@ This proposal specifies that all Fork ECIPs in `Draft` state or earlier should c ### Rationale -The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of `n >= 1` Standards-Core type ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." +The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of `n >= 1` Standards-Core type IPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." 0. "Shell" format Fork ECIPs represent a clear, albeit abstract, idea: The blockchain's next hard fork. From a4c7dd1ec7a87705ba9af9ee0153b252c0e89e72 Mon Sep 17 00:00:00 2001 From: meows Date: Sun, 1 Dec 2019 08:54:35 -0500 Subject: [PATCH 22/25] Note that Fork ECIPs can specify upgrades for multiple chains --- _specs/ecip-1077.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index d526bd72d..949dafab7 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -76,7 +76,7 @@ This proposal specifies that all Fork ECIPs in `Draft` state or earlier should c The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of `n >= 1` Standards-Core type IPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." -0. "Shell" format Fork ECIPs represent a clear, albeit abstract, idea: The blockchain's next hard fork. +0. "Shell" format Fork ECIPs represent a clear, albeit abstract, idea: One or many blockchains' next hard fork (eg. chains Ethereum Classic, Morden, Kotti). 1. __Demanding fully-formed Fork ECIP Changeset proposal forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Fork ECIP Changeset may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. The intention of this specification is make these logical steps as explicit and document and accessible as possible, in order that good decisions can be made with a process of open and constructive collaboration, enabled by named and concrete options. From 19dab4bf15895351267462c344358ab1094e245a Mon Sep 17 00:00:00 2001 From: meows Date: Wed, 4 Mar 2020 05:56:49 -0600 Subject: [PATCH 23/25] git checkout maste -- _specs/ecip-1000.md Signed-off-by: meows --- _specs/ecip-1000.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_specs/ecip-1000.md b/_specs/ecip-1000.md index 77a2d41a3..069490255 100644 --- a/_specs/ecip-1000.md +++ b/_specs/ecip-1000.md @@ -132,7 +132,7 @@ Each ECIP must begin with an RFC 822 style header preamble. The headers must app - **Comments-Summary:** (summary tone) - **Comments-URI:** (links to wiki page for comments) - **Status:** (Draft | Last Call | Accepted | Final | Deferred | Replaced | Rejected | Withdrawn) -- **Type:** (Standards Track | Informational | Meta | Fork) +- **Type:** (Standards Track | Informational | Process) - **Created:** (date created on, in ISO 8601 (yyyy-mm-dd) format) - **License:** (abbreviation for approved license(s)) - **License-Code:** (abbreviation for code under different approved license(s)) @@ -151,7 +151,7 @@ If there are multiple authors, each should be on a separate line following RFC 2 While an ECIP is in private discussions (usually during the initial Draft phase), a`Discussions-To` header will indicate the mailing list or URL where the ECIP is being discussed. No `Discussions-To` header is necessary if the ECIP is being discussed privately with the author. -The `Type` header specifies the type of ECIP: Standards Track, Informational, Meta, Fork. +The `Type` header specifies the type of ECIP: Standards Track, Informational, or Process. The `Created` header records the date that the ECIP was assigned a number. From 595ae62a0a6ed6f59ca98602326a864a8825bc4c Mon Sep 17 00:00:00 2001 From: meows Date: Wed, 4 Mar 2020 05:58:55 -0600 Subject: [PATCH 24/25] include ecip-X-FORK.md content in ecip itself Make changeset more streamlined. Signed-off-by: meows --- _specs/ecip-1077.md | 42 ++++++++++++++++++++++++++++++++++++++++++ ecip-X-FORK.md | 36 ------------------------------------ 2 files changed, 42 insertions(+), 36 deletions(-) delete mode 100644 ecip-X-FORK.md diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index 949dafab7..fa7acc476 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -72,6 +72,48 @@ _Unique_ means not the same as another thing; in this case, not precisely duplic This proposal specifies that all Fork ECIPs in `Draft` state or earlier should contain NO information about ECIP-sets or block activation numbers (all `TBD`). Proposed specifications to fill these placeholders should be made in the form of distinct and separate propsed change sets (eg Github Pull Requests) to the Fork ECIP document. The changesets are required to be UNIQUE and COMPLETE. +There might be an `ecip-X-FORK.md` file that would look something like this: + +``` +--- +lang: en +ecip: +title: +author: +discussions-to: +status: +type: Fork +created: +replaces: +superseded-by: +resolution: +--- + +### Abstract + +Specifying a next hardfork for the following networks: + +- +- + +### Motivation + +### Specification + +- __Block Activation Number(s)__: + + : `TBD` + + : `TBD` + +- __Feature specification(s)__: + + TBD + +### Rationale + +### Implementation + +### Copyright/Licensing +``` + ### Rationale The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of `n >= 1` Standards-Core type IPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment." diff --git a/ecip-X-FORK.md b/ecip-X-FORK.md deleted file mode 100644 index 86cc33b22..000000000 --- a/ecip-X-FORK.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -ecip: -title: -author: -discussions-to: -status: -type: Fork -created: -replaces: -superseded-by: -resolution: ---- - -### Abstract - -Specifying a next hardfork for the following networks: - -- -- - -### Motivation - -### Specification - -- __Block Activation Number(s)__: - + : `TBD` - + : `TBD` - -- __Feature specification(s)__: - + TBD - -### Rationale - -### Implementation - -### Copyright/Licensing From 5a7cc34ab0aa831b3b0140c5a37fb3d6c0a83527 Mon Sep 17 00:00:00 2001 From: meows Date: Wed, 4 Mar 2020 05:59:52 -0600 Subject: [PATCH 25/25] ECIP1077: status: withdrawn Signed-off-by: meows --- _specs/ecip-1077.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_specs/ecip-1077.md b/_specs/ecip-1077.md index fa7acc476..75211b148 100644 --- a/_specs/ecip-1077.md +++ b/_specs/ecip-1077.md @@ -3,7 +3,7 @@ ecip: 1077 title: The Meta Fork ECIP: Establishing _Fork_ type ECIPs and their specifications and processes author: Mr. Meows D. Bits discussions-to: TBD -status: WIP +status: Withdrawn type: Meta created: 2019-11-29 ---