Migrating Pantheon to Besu (hyperledger#1945)

Signed-off-by: Adrian Sutton <[email protected]>

.github/issue_template.md

@@ -1,10 +1,10 @@
 <!-- Have you done the following? -->
 <!--   * read the Code of Conduct? By filing an Issue, you are expected to -->  
 <!--     comply with it, including treating everyone with respect: -->
-<!--     https://github.com/PegasysEng/pantheon/blob/master/CODE-OF-CONDUCT.md -->
+<!--     https://github.com/hyperledger/besu/blob/master/CODE-OF-CONDUCT.md -->
 <!--   * Reproduced the issue in the latest version of the software -->
-<!--   * Read the debugging wiki: https://github.com/PegasysEng/pantheon/wiki/debugging -->
-<!--   * Duplicate Issue check:  https://github.com/search?q=+is%3Aissue+repo%3APegasysEng/Pantheon -->
+<!--   * Read the debugging wiki: https://github.com/hyperledger/besu/wiki/debugging -->
+<!--   * Duplicate Issue check:  https://github.com/search?q=+is%3Aissue+repo%3Ahyperledger/Besu -->
 <!-- Note:  Not all sections will apply to all issue types. -->
 
 ### Description
@@ -25,7 +25,7 @@ As an [Actor], I want [feature] so that [why].
 **Frequency:** [What percentage of the time does it occur?]
 
 ### Versions (Add all that apply)
-* Software version: [`pantheon --version`]
+* Software version: [`besu --version`]
 * Java version: [`java -version`]
 * OS Name & Version: [`cat /etc/*release`]
 * Kernel Version: [`uname -a`]

.github/pull_request_template.md

@@ -1,5 +1,5 @@
 <!-- Thanks for sending a pull request! Please check out our contribution guidelines: -->
-<!-- https://github.com/PegaSysEng/pantheon/blob/master/CONTRIBUTING.md -->
+<!-- https://github.com/hyperledger/besu/blob/master/CONTRIBUTING.md -->
 
 ## PR description
 

CLA.md

@@ -12,8 +12,8 @@ Individual Contributor License Agreement.
 3. After creating your first pull request, you will see a merge
    pre-requisite requiring to you read and sign the CLA.
 
-If you have any questions, you can reach us on [Gitter].
+If you have any questions, you can reach us on [RocketChat].
 
-[Gitter]: https://gitter.im/PegaSysEng/pantheon
+[RocketChat]: https://chat.hyperledger.org/channel/besu
 [GitHub]: https://github.com/
 [the current version of the CLA]: https://gist.github.com/rojotek/978b48a5e8b68836856a8961d6887992

CLI-STYLE-GUIDE.md

@@ -1,28 +1,28 @@
-# Pantheon Command Line Interface (CLI) Style Guide
+# Besu Command Line Interface (CLI) Style Guide
 
 ## Purpose of this Document
 
-This document contains guidelines to help the Pantheon command line interface (CLI) remain usable, modular, and extensible as it grows over time. This is a living document and should evolve to better suit end users and those who contribute to Pantheon.
+This document contains guidelines to help the Besu command line interface (CLI) remain usable, modular, and extensible as it grows over time. This is a living document and should evolve to better suit end users and those who contribute to Besu.
 
-> **Note:** Although not every pattern shown in this style guide is currently followed in Pantheon, it is our intention to revise and build new functionality with these guidelines in mind.
+> **Note:** Although not every pattern shown in this style guide is currently followed in Besu, it is our intention to revise and build new functionality with these guidelines in mind.
 
 **The primary audience for this document is:**
 
-*   Members of the Pantheon team
+*   Members of the Besu team
 *   Developers contributing pull requests
 
 ## Mission Statement
 
-The Pantheon CLI should create a consistent and easy to understand experience for end users. We're focused on creating a great developer experience for both new and expert users of Ethereum clients.
+The Besu CLI should create a consistent and easy to understand experience for end users. We're focused on creating a great developer experience for both new and expert users of Ethereum clients.
 
 ## General Guidelines
 
-There are four guiding principles for the Pantheon CLI to help us create a good developer experience for both new and expert users: **_(1) be consistent, (2) keep it simple, (3) be proactive, and (4) be informative (to people and machines)._**
+There are four guiding principles for the Besu CLI to help us create a good developer experience for both new and expert users: **_(1) be consistent, (2) keep it simple, (3) be proactive, and (4) be informative (to people and machines)._**
 
 This section outlines what each of these principles mean and the following sections explain how these principles should be applied in specific scenarios.     
 
 ### 1. Be Consistent
-Consistency is important to help our end users build a mental model of how Pantheon works. By being consistent with our word choices, visual formatting, and style of communication it helps users know what to expect as they interact with Pantheon.  
+Consistency is important to help our end users build a mental model of how Besu works. By being consistent with our word choices, visual formatting, and style of communication it helps users know what to expect as they interact with Besu.  
 
 ### 2. Keep it Simple
 Avoid technical jargon and always assume our end users may have questions. This doesn't mean answering all of those questions in the CLI, but it does mean explaining things in a simple way and when complexity inevitably rises, directing our users to documentation that will help them.
@@ -31,7 +31,7 @@ Avoid technical jargon and always assume our end users may have questions. This
 Being proactive means anticipating user needs and guiding them through a process. This most often takes the form of solution-oriented warning/error messages. Put yourself in the user's shoes and consider what questions you would have every time we are showing feedback or status to them.
 
 ### 4. Be Informative (to people and machines)
-We seek a balance between providing enough relevant information to help our users develop a solid mental model of how Pantheon works without forcing them to read too much text. In addition, it is important we consider not only the end user of the CLI but to be consistent with formatting and feedback so information is easily interpreted by machines.
+We seek a balance between providing enough relevant information to help our users develop a solid mental model of how Besu works without forcing them to read too much text. In addition, it is important we consider not only the end user of the CLI but to be consistent with formatting and feedback so information is easily interpreted by machines.
 
 ## User Input & Actions
 
@@ -47,9 +47,9 @@ A subcommand is an action that can be taken on a single object (i.e. import, exp
 
 **Examples:**
 
-`pantheon blocks import`
+`besu blocks import`
 
-`pantheon public-key export`
+`besu public-key export`
 
 Although noun-verb formatting seems backwards from a speaking perspective (i.e. blocks import vs. import blocks) it allows us to organize commands the same way users think about completing an action (the topic first, then the action).
 
@@ -58,9 +58,9 @@ Although noun-verb formatting seems backwards from a speaking perspective (i.e.
 
 Using required options instead of arguments helps users have a clear understanding of the impact of an action. Inputs are most often verbs (from, to, etc.). Other options avoid the use of verbs to help make this distinction.
 
-**Example:** `pantheon blocks import --from=<FILE>`
+**Example:** `besu blocks import --from=<FILE>`
 
-Requiring the `--from` option makes it clear where you are importing from. In the case of a single parameter (as shown in the example above) we should also accept this as an argument (`pantheon blocks import <FILE>`). Although we accept this formatting, it is not encouraged and should be excluded from our documentation.
+Requiring the `--from` option makes it clear where you are importing from. In the case of a single parameter (as shown in the example above) we should also accept this as an argument (`besu blocks import <FILE>`). Although we accept this formatting, it is not encouraged and should be excluded from our documentation.
 
 ### Flags
 
@@ -101,7 +101,7 @@ Options are used for settings, like specifying a configuration file or to provid
 
 ### General Naming Guidelines
 
-Words matter. Most users will not be interacting with Pantheon on a regular basis so we should name things for ease of understanding.
+Words matter. Most users will not be interacting with Besu on a regular basis so we should name things for ease of understanding.
 
 * Don't use abbreviations unless they are widely understood. Optimize for understanding, not number of characters.
 

CODING-CONVENTIONS.md

@@ -30,13 +30,13 @@ Simple does not mean the fewest lines of code. Simple code is:
 * Usually the most performant. Without data showing another approach is faster, stick with the simple design 
 * Not simplistic:
 
-  - Ethereum is complex and Pantheon must handle this complexity and operate correctly and securely 
-  - Pantheon code should align with well-established Ethereum abstractions and terminology used in Ethereum specifications 
+  - Ethereum is complex and Besu must handle this complexity and operate correctly and securely 
+  - Besu code should align with well-established Ethereum abstractions and terminology used in Ethereum specifications 
   - Aim to make the code as simple as possible but no simpler
 
 ## 2.2 Idiomatic Java 
 
-Pantheon embraces typical Java idioms including using an Object Oriented approach to design. This includes:   
+Besu embraces typical Java idioms including using an Object Oriented approach to design. This includes:   
 * Providing alternate behaviours via polymorphism instead of having conditional logic scattered through the codebase. For example, `ProtocolSpec` provides a standard interface to blockchain operations and multiple implementations define the different behaviours for each Ethereum milestone. 
 * Encapsulating behaviour and data together in classes. For example, `BytesValue` encapsulates byte data and methods operating on the byte data. `BytesValue.isZero()` is an instance method instead of accepting a `BytesValue` parameter.
 
@@ -47,11 +47,11 @@ Pantheon embraces typical Java idioms including using an Object Oriented approac
    - Don't pass lambdas into executors because it makes it harder to identify the threading interactions. The lambda makes the code shorter but not clearer. Instead use a separate class or extract a method. 
 * For good examples, refer to the APIs the JDK itself exposes. 
 
->**Note** If you're not sure what idiomatic Java looks like, start by following the typical patterns and naming used in Pantheon.
+>**Note** If you're not sure what idiomatic Java looks like, start by following the typical patterns and naming used in Besu.
 
 ## 2.3 You Ain't Gonna Need It (YAGNI)
 
-The Pantheon design prioritizes meeting current requirements in the simplest, clearest way over attempting to anticipate future functionality. As a result, Pantheon’s design:
+The Besu design prioritizes meeting current requirements in the simplest, clearest way over attempting to anticipate future functionality. As a result, Besu’s design:
 * Is not set in stone as a big upfront design. The design is adjusted through constant refactoring as new requirements are added and understood.
 * Uses abstraction only where it aids understanding of the current code. Abstraction is not used where it only supports future needs.
 * Avoids over-engineering.
@@ -100,7 +100,7 @@ So the code can cope with constant refactoring and evolving design, write code t
 
 * Uses dependency injection
   - Constructors should be simple, with dependencies passed in rather than built in the constructor
-  - Pantheon does not use a dependency injection framework
+  - Besu does not use a dependency injection framework
 
 * Validates method parameters for public methods using the Guava `Preconditions` class. Avoid validating parameters in private methods
 
@@ -113,7 +113,7 @@ So the code can cope with constant refactoring and evolving design, write code t
 
 * Use Optional rather than returning null when not having a value is a normal case
 
-* Consider exception and error handling as part of the overall design.   Pantheon avoids checked exceptions
+* Consider exception and error handling as part of the overall design.   Besu avoids checked exceptions
 
 * Give threads meaningful names. For example:
  `Executors.newFixedThreadPool(1, new ThreadFactoryBuilder().setNameFormat(“Ibft”).build())`
@@ -123,7 +123,7 @@ So the code can cope with constant refactoring and evolving design, write code t
 
 ## 4.1 Style Guide 
 
-Pantheon follows the [Google code style](https://google.github.io/styleguide/javaguide.html) and uses spotless to ensure consistency of formatting. 
+Besu follows the [Google code style](https://google.github.io/styleguide/javaguide.html) and uses spotless to ensure consistency of formatting. 
 
 To automatically reformat the code before creating a pull request, run: 
 
@@ -182,7 +182,7 @@ Method parameters must be final.  Class level and local fields should be final w
 
 # 5 Logging
 
-Logging is important for understanding what Pantheon is doing at any given time (for example, progress while synchronizing) and investigating defects.  During development, add logging to aid in these cases. 
+Logging is important for understanding what Besu is doing at any given time (for example, progress while synchronizing) and investigating defects.  During development, add logging to aid in these cases. 
 
 ## 5.1 Log Messages
 
@@ -213,12 +213,12 @@ Make log messages:
 
 * _Warn_ 
 
-  Anything that can potentially cause application oddities but from which Pantheon automatically recovers
+  Anything that can potentially cause application oddities but from which Besu automatically recovers
 
 * _Error_ 
 
-  Any error which is fatal to the operation, but not Pantheon itself (for example, missing data)
+  Any error which is fatal to the operation, but not Besu itself (for example, missing data)
 
 * _Fatal_  
 
-  An error that forces a shutdown of Pantheon
+  An error that forces a shutdown of Besu