Title: Ethereum_Engineering_Processes__standardized_workf
Category: Magicians

Author: jpitts
Date: 2018-11-06T17:39:31.299Z

Everyone hates checklists, but Ethereum will only reach its potential if we can regulate it with the gravity of flight engineering.

“Ethereum Engineering Processes” is an excellent resource proposed / created by @karalabe.
He starts by proposing EEP-1, a workflow for network participants on how to roll out consensus upgrades onto the Ethereum mainnet reliably and reproducibly.


github.com/karalabe/eee


eeps/eep-1.md

master

---
EEP:     1
Title:   Consensus update rollout
Authors: Péter Szilágyi <peter@ethereum.org>
Status:  Draft
Version: 2018-11-06
Discuss:
---

*Ethereum is a mission critical system, the long-term sustainability of which requires strict engineering practices over rock-star development. Part of that effort is ensuring we have well defined processes that all ecosystem participants understand, agree with and adhere to. Everyone hates checklists, but Ethereum will only reach its potential if we can regulate it with the gravity of flight engineering.*

*All amendments to this standardized workflow must be rationalized via real world failures, which must be included for future reference to avoid regressions. When adding a new item, please also include an inline explanation to help newcomers.*

## Abstract

The goal of this document is to act as a step-by-step guide for network participants on how to roll out consensus upgrades onto the Ethereum network in a reliable and reproducible fashion. It defines the timelines and deliverables different teams must follow, as well as the emergency procedures in case something foreseeable goes wrong.

The scope of this document is *not* the specification, implementation and preparation of forks. Rather, the scope of this document is to outline their safe rollout once the ecosystem gives the green light on deploying them.

## Preconditions




  This file has been truncated. show original





Related to this topic are recent posts about the disorderly Constantinople-related fork on Ropsten:




Issues we discovered in the Ropsten Constantinople hard fork Process Improvement


    Here’s my initial post-mortem and concern/task list following the Constantinople Ropsten hard fork, in no particular order. 


A consensus bug in Parity was discovered (https://github.com/paritytech/parity-ethereum/pull/9746). We need to understand why this consensus bug occurred in the first place, and particularly why it wasn’t caught by the tests. @ethchris suggests that we may need clearer EIP specs including pseudo code (https://twitter.com/ethchris/status/1052503731072315392). Apparently i…
  





Disorderly Constantinople fork on Ropsten testnet Signaling Ring


    This case brings up interesting developer coordination issues and illustrates the importance of a well-defined testing process as client developers prepare to implement changes affecting mainnet. 
In this planned activation of changes on Ropsten testnet, when the forking block was reached, there was not enough mining power from Ropsten clients implementing Constantinpole changes. This led to a disorderly forking in which the intended upgraded network failed to quickly materialize / become domina…
  





A case to study: proposed Constantinople-related fork on Ropsten Signaling Ring


    Context: AllCoreDevs meetings notes #47 on Fri, September 28, 2018 

“Geth, Parity, aleth, ethereumj, mana, nethermind - completed implementation of all EIPs” 
“we should probably pick a block number today for testnet fork” 
“Let’s go with Ropsten block 4.2M, that puts us at this time in 11 days, on Oct. 9” 

Certain client development stakeholders wanted to activate forking changes / Constantinople in order to identify possible consensus bugs and reduce risks for when these changes are activate…