diff --git a/docs/README.rst b/docs/README.rst index 5491872ee7dd5c835c32f43a1c863489e40c75ee..3f09839134973aafba7ca4af730bdc5c691c02bf 100644 --- a/docs/README.rst +++ b/docs/README.rst @@ -63,12 +63,12 @@ Odoc is used for OCaml API generation. You can install Odoc with: opam install odoc -Tezos generates the API documentation for all libraries in HTML format. The +Octez generates the API documentation for all libraries in HTML format. The generated HTML pages are put in ``_build//_doc``. It creates one sub-directory per public library and generates an ``index.html`` file in each sub-directory. -The documentation is not installed on the system by Tezos. It is meant to be +The documentation is not installed on the system by Octez. It is meant to be read locally while developing and then published on the www when releasing packages. @@ -172,11 +172,11 @@ This better way is to write "executable documentation". The idea is to write such executable scripts separated from the documentation, and to automatically copy them in the documentation whenever it is (re)generated. Executable documentation allows one to test those scripts, e.g. in CI (continuous integration), ensuring they work and are up to date with the code and with its environment. -Typically, Tezos installation scripts not only have to evolve with the Tezos codebase, but also with various other evolving resources, such as OPAM packages, package managers, Linux distributions, and so on. +Typically, Octez installation scripts not only have to evolve with the Octez codebase, but also with various other evolving resources, such as OPAM packages, package managers, Linux distributions, and so on. By continuously testing such installation scripts, executable documentation allows one to detect problems and fix obsolete instructions as early as possible, avoiding headaches and frustration, for new end users and experienced developers alike. Technically, executable documentation can be created by using the Sphinx directive `literalinclude `_, which may include whole scripts or parts of them. -For example, the following directive includes a script fragment detailing a step in compiling the Tezos sources:: +For example, the following directive includes a script fragment detailing a step in compiling the Octez sources:: .. literalinclude:: compile-sources.sh :language: shell diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index 5854de0371ab0e8a6f7ac67900ba3fc4e06999f5..e684ca1912b069acaa3da433a4d5674f93a90e2c 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -12,10 +12,10 @@ paper `_. The reference implementation of Sapling, `librustzcash `_, was -integrated in the Tezos codebase during 2019. It will be proposed as +integrated in the Octez codebase during 2019. It will be proposed as part of a protocol amendment during 2020. -Librustzcash and the Tezos integration implement the protocol +Librustzcash and the Octez integration implement the protocol described in this `specification `_, version 2020.1.0. @@ -442,7 +442,7 @@ Client Under `lib_client_sapling` there is the client integration with the support for Sapling keys and forging of transactions. -The main difference from the existing Tezos client is the need for the +The main difference from the existing Octez client is the need for the Sapling client to keep an additional state, for each contract. Because Sapling uses a UTXO model it is necessary for a client to compute the set of unspent outputs in order to forge new transactions. diff --git a/docs/alpha/smart_rollups.rst b/docs/alpha/smart_rollups.rst index 8cf89d8754709f5e27b9de22c96ed0bcf645af3d..d019ad433fefd107f2b6e1cda33b88fdce5da9c1 100644 --- a/docs/alpha/smart_rollups.rst +++ b/docs/alpha/smart_rollups.rst @@ -308,7 +308,7 @@ docker images or can be compiled from sources. Please refer to the `Dailynet `_ website for installation details. -An Octez rollup node needs an Octez tezos node to run. We assume that +An Octez rollup node needs an Octez node to run. We assume that a rollup node has been launched locally, typically by issuing: .. code:: sh diff --git a/docs/alpha/validation.rst b/docs/alpha/validation.rst index be828c88c56f1b724b437b132913b47e77f17989..79e1146b909e70957aee3de4259c64d1d308de92 100644 --- a/docs/alpha/validation.rst +++ b/docs/alpha/validation.rst @@ -85,12 +85,12 @@ Validation modes ================ The Tezos protocol provides different validation modes, intended to be -used by Tezos *shell* and *baker* software implementations when +used by the Tezos *shell* and *baker* software implementations when needing to apply (or to assert the validity) of blocks and operations under different, or specialized, circumstances -- for example, in order to *bake* a block. For each of these validation modes, the API specified by the protocol environment offers an entry point so that -protocol-agnostic components, the Octez shell for instance, are able +protocol-agnostic components, the Tezos shell for instance, are able to use these different modes. .. _full_application_alpha: diff --git a/docs/alpha/voting.rst b/docs/alpha/voting.rst index 888bace2e1cb92455a3c39e0f613e9bfd6472bf9..ae8f1bb07950fcbeb9862554b1a39ffd1a852a03 100644 --- a/docs/alpha/voting.rst +++ b/docs/alpha/voting.rst @@ -258,7 +258,7 @@ interaction with the amendment and voting process. Show ~~~~ -Tezos' client provides a command to show the status of a voting period. +The client provides a command to show the status of a voting period. It displays different information for different kind of periods, as in the following samples:: diff --git a/docs/api/openapi.rst b/docs/api/openapi.rst index dec5c2c65284b9e285d49e911bfdca2de504ff81..cec1caa8282583ecf5362f7546e764a5fafc74ca 100644 --- a/docs/api/openapi.rst +++ b/docs/api/openapi.rst @@ -68,7 +68,7 @@ How to Generate --------------- To generate the above files, run the ``src/bin_openapi/generate.sh`` script -from the root of the Tezos repository. +from the root of the Octez repository. It will start a sandbox node, activate the protocol, get the RPC specifications from this node and convert them to OpenAPI specifications. diff --git a/docs/developer/contributing-adding-a-new-opam-dependency.rst b/docs/developer/contributing-adding-a-new-opam-dependency.rst index 36f52b196d581a28c1cde4a27ece4390875547ab..07be56ef5c88beaa9cf61204340230253c4c5058 100644 --- a/docs/developer/contributing-adding-a-new-opam-dependency.rst +++ b/docs/developer/contributing-adding-a-new-opam-dependency.rst @@ -12,8 +12,8 @@ If you have already read this guide and only need a refresher, skip to the Background ---------- -The Tezos project is built under a system that is somewhat stricter than -the default for OCaml project. Specifically, the Tezos project maintains +The Octez project is built under a system that is somewhat stricter than +the default for OCaml project. Specifically, the Octez project maintains a dedicated opam package repository that is a strict subset of the opam default one; all binaries are built with dependencies from this subset only. @@ -35,10 +35,10 @@ Local work ---------- The simplest way of working locally (i.e., on your own machine) on the -Tezos codebase, using a new dependency is to install it using ``opam``. +Octez codebase, using a new dependency is to install it using ``opam``. Because you have used ``make build-dev-deps`` in order to install the -Tezos dependencies, you have access to the default opam repository in +Octez dependencies, you have access to the default opam repository in addition to the dedicated one. **Install your dependency:** ``opam install foo`` @@ -70,7 +70,7 @@ the CI of the dedicated ``opam-repository``. You must follow the steps below in order to produce the necessary Docker images, allowing your work to eventually be merged. -First, in your local copy of Tezos, **update the** +First, in your local copy of Octez, **update the** ``full_opam_repository_tag`` **variable in the** :src:`scripts/version.sh` **file**. You should set this variable to the hash of the ``HEAD`` commit on @@ -78,7 +78,7 @@ should set this variable to the hash of the ``HEAD`` commit on (Note: this is not always necessary, but it is simpler for you to do so than to check whether it is necessary to do so.) -Second, still in your local copy of Tezos, **execute the** +Second, still in your local copy of Octez, **execute the** :src:`scripts/update_opam_repo.sh` **script**. This script uses the content of your :src:`opam/` directory to create a file called ``opam_repo.patch``. This file represents the diff between the current @@ -92,7 +92,7 @@ work. Third, **create an MR on the dedicated opam repository that includes your patch.** This is the *opam repository MR*, its role is to prepare -the environment for your existing *Tezos MR*. +the environment for your existing *Octez MR*. In order to create the opam repository MR: @@ -107,7 +107,7 @@ You can test the MR locally using the command ``OPAM_REPOSITORY_TAG= make build-deps``. This will rebuild the dependencies locally using the ```` of the opam-repository. -Fourth, back in your local copy of Tezos, **update the variables in the** +Fourth, back in your local copy of Octez, **update the variables in the** :src:`.gitlab-ci.yml` **and** :src:`scripts/version.sh` **files**. Specifically, set the ``build_deps_image_version`` and the ``opam_repository_tag`` variables to the hash of the ``HEAD`` commit of the opam repository MR. Commit @@ -116,18 +116,18 @@ this change with a title along the lines of “CI: use dependency This commit will point the build scripts and CI to the modified opam-repository and the associated Docker images. Do note that the CI on your -branch of Tezos will only be able to run after the CI on your branch of +branch of Octez will only be able to run after the CI on your branch of opam-repository has completed. -Fifth, still in your local copy of Tezos, **push these changes and open or +Fifth, still in your local copy of Octez, **push these changes and open or update the MR**. Make sure you add links referencing the opam-repository MR from -the Tezos MR and vice-versa. This gives the reviewers the necessary context to +the Octez MR and vice-versa. This gives the reviewers the necessary context to review. That’s it. You now have two MRs: -- The *opam-repository MR* from ``tezos/opam-repository:`` onto ``tezos/opam-repository:master`` updates the environment in which the Tezos libraries and binaries are built. -- The *tezos MR* from ``/tezos:`` onto ``tezos/tezos:master`` uses this new environment. +- The *opam-repository MR* from ``tezos/opam-repository:`` onto ``tezos/opam-repository:master`` updates the environment in which the Octez libraries and binaries are built. +- The *Octez MR* from ``/tezos:`` onto ``tezos/tezos:master`` uses this new environment. Merging the MR -------------- @@ -153,7 +153,7 @@ introduce a merge commit. After the merge, **the HEAD commit of master should be the HEAD of the branch you just merged**. This is important because it ensures the Docker images have the same name. -Second, **assign the Tezos MR to margebot** for merging. +Second, **assign the Octez MR to margebot** for merging. .. _tldr: @@ -162,14 +162,14 @@ TL;DR As a developer: -- You have a Tezos MR from ``/tezos:`` onto ``tezos/tezos:master`` introducing a dependency to ``foo``. +- You have an Octez MR from ``/tezos:`` onto ``tezos/tezos:master`` introducing a dependency to ``foo``. - You amend the :src:`manifest/main.ml` file to declare the dependency. - You propagate the changes to ``opam`` and ``dune`` files by running ``make -C manifest`` - You update the ``full_opam_repository_tag`` to the HEAD commit hash from the public default opam repository. - You execute :src:`scripts/update_opam_repo.sh`. - You open an opam repository MR from ``tezos/opam-repository:`` onto ``tezos/opam-repository:master`` that includes the generated patch. - You update ``build_deps_image_version`` and ``opam_repository_tag`` to the hash of the ``HEAD`` commit of your opam repository MR. -- You push the changes to your Tezos MR. +- You push the changes to your Octez MR. - You update the description of your MRs to include links. As a merger: @@ -177,4 +177,4 @@ As a merger: - You test, review, etc. the code. - You merge the opam repository MR. - You make sure the commit hash has been preserved by merging (no squashing, no merge-commits) -- You assign the Tezos MR to margebot. +- You assign the Octez MR to margebot. diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst index 7fa154ed635972dee7848c7ca5f417687ec2228b..8376e7561a9e1c2984b5b996a72b4226a13f899e 100644 --- a/docs/developer/contributing.rst +++ b/docs/developer/contributing.rst @@ -56,7 +56,7 @@ First, make sure that you are proficient enough in OCaml. The community website https://ocaml.org gives a few useful pointers for that. In particular, we use a lot of functors, and a few GADTs in the codebase, so you may want to make sure that you master these advanced concepts. -For a more specific explanation of GADT usage in Tezos you can check out +For a more specific explanation of GADT usage in Octez you can check out :doc:`gadt`. Then, if you don’t know much about the Lwt library, that’s what you want @@ -228,7 +228,7 @@ While working on your branch to prepare a Merge Request, make sure you respect t into account the impact on :ref:`RPC security `. - If you modify the user API (e.g. add or change a configuration parameter or a command-line option), update the corresponding documentation. In - particular, for configuration parameters of the Tezos node, update the node + particular, for configuration parameters of the Octez node, update the node configuration :doc:`documentation <../user/node-configuration>` and the documentation of the modified component(s), usually referred by that page. - If your MR introduces new dependencies, follow the @@ -580,7 +580,7 @@ description what was tested and how so that **reviewers can reproduce it**. Code Review ----------- -At Tezos all the code is peer reviewed before getting committed in the +All code is peer reviewed before getting committed in the master branch by the :doc:`Octez merge team `. Briefly, a code review is a discussion between two or more developers about changes to the code to address an issue. diff --git a/docs/developer/data_encoding.rst b/docs/developer/data_encoding.rst index eb83baa304066ac90a09c98e5adc2446e4f750d0..db9375c43f6b7632cd58e28af4eb73b4bd4825f0 100644 --- a/docs/developer/data_encoding.rst +++ b/docs/developer/data_encoding.rst @@ -89,7 +89,7 @@ And the encoders for these types as Union types ~~~~~~~~~~~ -The Tezos codebase makes heavy use of variant types. Consider the +The Octez codebase makes heavy use of variant types. Consider the following variant type: .. code-block:: ocaml diff --git a/docs/developer/entering_alpha.rst b/docs/developer/entering_alpha.rst index 3ba80b7b299862d9130fe9228d90eee695e648ea..9ecb1de5065a6f5c0396727a4fcfaea380cce47c 100644 --- a/docs/developer/entering_alpha.rst +++ b/docs/developer/entering_alpha.rst @@ -192,7 +192,7 @@ sure that the URL schemes and JSON formats and consistent between the two parties. These two features are extremely useful when refactoring, as the OCaml typechecker will help us track the effects of an RPC API change on the whole codebase. The third purpose is of course, to make -automatic documentation generation possible (as in ``tezos client rpc +automatic documentation generation possible (as in ``octez-client rpc list/format``). Each service is also accompanied by a caller function, that can be used from the client to perform the calls, and by the tests to simulate calls in a fake in-memory context. diff --git a/docs/developer/error_monad_p4_appendices.rst b/docs/developer/error_monad_p4_appendices.rst index 6cac193aac6af826a8ec2f7b17283f26a592e9e3..69e2b1bd9a616de1d4f93a4ab5e83e1fc83116b5 100644 --- a/docs/developer/error_monad_p4_appendices.rst +++ b/docs/developer/error_monad_p4_appendices.rst @@ -489,7 +489,7 @@ following code fragment? | Cons: a single kind of errors means it cannot be very informative. Option is a common enough strategy that the ``Option_syntax`` and -``Lwt_option_syntax`` modules are available in the Tezos source. +``Lwt_option_syntax`` modules are available in the Octez source. **fallback** diff --git a/docs/developer/gadt.rst b/docs/developer/gadt.rst index 3d1b4ebee7e92961e6933cbcbd18c1c71d58236e..edba5fb0551b835e4c42063544b99a1dc0cc3f3b 100644 --- a/docs/developer/gadt.rst +++ b/docs/developer/gadt.rst @@ -2,10 +2,10 @@ Generalized Algebraic Data Types (GADTs) ======================================== -GADTs are a recent extension of OCaml, which is widely used in the Tezos +GADTs are a recent extension of OCaml, which is widely used in the Octez code-base, especially in the protocol. They serve many important purposes, most notably increasing type safety of the Michelson interpreter. This page reviews -some of the use cases of GADTs in Tezos codebase and explains what role do they +some of the use cases of GADTs in Octez codebase and explains what role do they play in the design. For an explanation of the GADT concept itself, try one of the links below: @@ -18,7 +18,7 @@ For an explanation of the GADT concept itself, try one of the links below: Ensuring type safety of the Michelson interpreter ================================================= -One of the most important use cases for GADTs in Tezos is ensuring type safety +One of the most important use cases for GADTs in Octez is ensuring type safety of the Michelson interpreter. Obviously, because Michelson scripts manage possibly large amounts of funds, it is extremely important that the interpreter is bug-free and reliable. The static type checking of Michelson expressions diff --git a/docs/developer/guidelines.rst b/docs/developer/guidelines.rst index 2ef5c923b2b3c4f42cbd433cb0f1a8329b57539e..52f9653feba4d1465b38379647325b0742a536ab 100644 --- a/docs/developer/guidelines.rst +++ b/docs/developer/guidelines.rst @@ -1,12 +1,12 @@ Coding guidelines ================= -This document provides guidelines that should be observed by all the contributors to the Tezos codebase. It first presents documentation guidelines, and then rules more specific to coding (e.g., logging levels, code formatting, naming conventions, etc.). +This document provides guidelines that should be observed by all the contributors to the Octez codebase. It first presents documentation guidelines, and then rules more specific to coding (e.g., logging levels, code formatting, naming conventions, etc.). License ------- -The Tezos software is distributed under the MIT license. Every OCaml source file should start with a header comment instantiating the following template (use appropriate comment syntax for other languages): +The Octez software is distributed under the MIT license. Every OCaml source file should start with a header comment instantiating the following template (use appropriate comment syntax for other languages): .. literalinclude:: LICENSE.ml :language: ocaml @@ -150,7 +150,7 @@ README files ------------ Also at the level of the library, you should include a ``README.md`` in `Markdown format `_. -Such files are mandatory in top-level directories of the Tezos codebase (such as ``src/`` and ``docs/``), and at least in immediate sub-directories of the source directory (``src/*/``). +Such files are mandatory in top-level directories of the Octez codebase (such as ``src/`` and ``docs/``), and at least in immediate sub-directories of the source directory (``src/*/``). Because it is accessible only in the source tree, the file should contain information that might be of interest to the maintainers and contributors. You must instantiate the ``README.md`` file with the following template: @@ -199,7 +199,7 @@ the template, and address any gap if needed. Logging Levels -------------- -The Tezos libraries use an logging library with 5 different verbosity `levels` +The Octez libraries use a logging library with 5 different verbosity `levels` defined in ``src/lib_event_logging/internal_event.mli`` for shell and ``src/lib_protocol_environment/sigs/v3/logging.mli`` for protocol code. @@ -620,6 +620,6 @@ Coding conventions ------------------ Other than the guidelines above, there are currently no coding -conventions enforced in the codebase. However, Tezos developers should be aware +conventions enforced in the codebase. However, Octez developers should be aware of general `OCaml programming guidelines `_, which recommend formatting, naming conventions, and more. diff --git a/docs/developer/ppx_expect.rst b/docs/developer/ppx_expect.rst index 726e51cb545dd0514f86440765c575924ceb5cfd..ef9f727a537f8f01cb85ddc8a726a2eff154219f 100644 --- a/docs/developer/ppx_expect.rst +++ b/docs/developer/ppx_expect.rst @@ -8,7 +8,7 @@ There is pretty comprehensive documentation about ``Inline expectation tests`` a - `Dune documentation about inline expectation tests `_. - `Ppx_expect README `_. -Here, we will just cover enough to get started using them inside the Tezos codebase. +Here, we will just cover enough to get started using them inside the Octez codebase. How to run tests ---------------- @@ -148,5 +148,5 @@ Integration with Lwt Ppx_expect can be used in combination with Lwt, see the `README `_. -This integration has not been tested on the Tezos codebase yet, hence some work will be +This integration has not been tested on the Octez codebase yet, hence some work will be needed to a have specific support for the codebase. diff --git a/docs/developer/profiling.rst b/docs/developer/profiling.rst index 5a1fb47f57f3b623ae988e0d472d08bb0bc65a99..cf76e2dcf0331e762076eb61102fb1a8d0acee69 100644 --- a/docs/developer/profiling.rst +++ b/docs/developer/profiling.rst @@ -1,4 +1,4 @@ -Profiling the Tezos node +Profiling the Octez node ======================== Memory profiling the OCaml heap diff --git a/docs/developer/python_testing_framework.rst b/docs/developer/python_testing_framework.rst index 9ad1a0a42a097f37343973614f10e68a7b8dd86e..d13f80b9b59daba015fbe5ab72c87e97bd328411 100644 --- a/docs/developer/python_testing_framework.rst +++ b/docs/developer/python_testing_framework.rst @@ -35,7 +35,7 @@ Installation Prerequisites: -- The Tezos binaries :ref:`compiled from sources ` +- The Octez binaries :ref:`compiled from sources ` - `python 3.10.9`. It is recommended to use `pyenv `_ to manage the python versions. If you want to use ``pyenv``: diff --git a/docs/developer/repository_scope.rst b/docs/developer/repository_scope.rst index 211fade76929ba9781d5524c1e033bc25f8bf862..b2f441d63b42de6b6e8925a39d4458b92fc6eb91 100644 --- a/docs/developer/repository_scope.rst +++ b/docs/developer/repository_scope.rst @@ -13,7 +13,7 @@ and so on. Some of these libraries, such as ``lib_rpc`` or ``lib_error_monad``, constitute an integral part of the project, in that they are directly linked -to Tezos executables, while others, like ``lib_benchmark`` are used in +to Octez executables, while others, like ``lib_benchmark`` are used in the development process as tools which allow developers to make the software better. @@ -21,7 +21,7 @@ Sometimes such a helper project is developed independently at first, but later during its development it becomes significantly coupled to one or more libraries developed as part of the Octez project. Maintaining such a tool is frustrating, because it often breaks due to -changes in the Tezos libraries it depends upon. A possible solution to +changes in the Octez libraries it depends upon. A possible solution to this problem would be to include the tool in ``tezos/tezos`` repository and develop it together with Octez, which allows to discover breakages more quickly and prevent or fix them immediately. @@ -37,10 +37,10 @@ external project should fulfill *all* the following criteria: inter-process communication via RPC. #. The dependency mentioned above should be unavoidable. That is, if there is another way to build the project, avoiding depending - on internals of Tezos, adding such an optional dependency won't qualify + on internals of Octez, adding such an optional dependency won't qualify a project to be included. #. The dependency should be on a feature or part of the codebase that is unstable enough to make it impractical to depend on released versions of Octez. -#. The project should be used regularly as a helper in developing Tezos (e.g. +#. The project should be used regularly as a helper in developing Octez (e.g. run in the CI pipeline). diff --git a/docs/developer/rpc.rst b/docs/developer/rpc.rst index fbf500cc8ef3600dafa59063a444df80d33308c1..50b0bb74beaf9c7c8f909cfd35253a6fc5266bfd 100644 --- a/docs/developer/rpc.rst +++ b/docs/developer/rpc.rst @@ -1,7 +1,7 @@ JSON/RPC interface ================== -The Tezos node provides a JSON/RPC interface. Note that it is an RPC, +The Octez node provides a JSON/RPC interface. Note that it is an RPC, and it is JSON based, but it does not follow the “JSON-RPC” protocol. It is not active by default and it must be explicitly activated with the ``--rpc-addr`` option. Typically, if you are not trying to run a local @@ -13,7 +13,7 @@ network and just want to explore the RPC, you would run: The RPC interface is self-documented and the ``octez-client`` executable is able to pretty-print the RPC API. For instance, to see the API -provided by the Tezos Shell: +provided by the Octez Shell: :: diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index d028c2d941ba226a5d40dd01dc091e125a5d7166..117be1bcc0e8e50d306e0a3ae50129198f1ae090 100644 --- a/docs/developer/testing.rst +++ b/docs/developer/testing.rst @@ -1,15 +1,15 @@ -Overview of Testing in Tezos +Overview of Testing in Octez ============================ The goal of this document is to give an overview on how testing is done in -Tezos, and to help Tezos contributors use the test suite and +Octez, and to help Octez contributors use the test suite and write tests by pointing them towards the most appropriate testing framework for their use case. Finally, this guide -explains how tests can be :ref:`run automatically in the Tezos CI +explains how tests can be :ref:`run automatically in the Octez CI ` and how to :ref:`measure test coverage `. -The frameworks used in Tezos can be categorized along two axes: the +The frameworks used in Octez can be categorized along two axes: the type of component they test, and the type of testing they perform. We distinguish the following components: @@ -56,7 +56,7 @@ Acceptance testing Testing of the software in real conditions. It is usually slower, more costly and less amenable to automation than integration or system testing. It is often the final step in the testing process, - performed before a release. However, in Tezos, acceptance testing + performed before a release. However, in Octez, acceptance testing is decoupled from releases, and currently consists in manually running a net of resilience tests on a regular base. These tests use various testing frameworks. @@ -79,7 +79,7 @@ in more detail. MT: :ref:`Michelson unit tests `. -.. csv-table:: Testing frameworks and their applications in Tezos. PT: +.. csv-table:: Testing frameworks and their applications in Octez. PT: :ref:`Python testing and execution framework `, EXP: :ref:`ppx_expect_section`, AT: :ref:`alcotest_section`, PBT: :ref:`property_based_test`, TZ: :ref:`tezt_section`, LTF: :ref:`long_tezt_section` :header: "Component","Unit","Property","Integration","System","Regression","Performance" @@ -102,7 +102,7 @@ Alcotest `Alcotest `_ is a library for unit and integration testing in OCaml. Alcotest is the primary tool in -Tezos for unit and integration testing of OCaml code. +Octez for unit and integration testing of OCaml code. Typical use cases: - Verifying simple input-output specifications for functions with a @@ -112,11 +112,11 @@ Typical use cases: Example tests: - Unit tests for :src:`src/lib_requester`, in :src:`src/lib_requester/test/test_requester.ml`. To execute them locally, run ``dune build @src/lib_requester/runtest`` in - the Tezos root. + the Octez root. - Integration tests for the P2P layer in the shell. For instance :src:`src/lib_p2p/test/test_p2p_pool.ml`. This test forks a set of processes that exercise large parts of the P2P layer. To execute - it locally, run ``dune build @runtest_p2p_pool`` in the Tezos + it locally, run ``dune build @runtest_p2p_pool`` in the Octez root. References: @@ -139,11 +139,11 @@ Typical use cases: Example tests: - Unit tests for :src:`src/lib_micheline`, in :src:`src/lib_micheline/test/test_parser.ml`. To execute them locally, run ``dune runtest src/lib_micheline/test`` in - the Tezos root. + the Octez root. References: - - :doc:`Section in Tezos Developer Documentation on Ppx_expect ` + - :doc:`Section in Octez Developer Documentation on Ppx_expect ` - `Ppx_expect README `_. - `Dune documentation about inline expectation tests `_. - `Ppx_inline_test README `_. @@ -172,7 +172,7 @@ References: Python testing and execution framework ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Tezos project uses `pytest `_, a Python testing +The Octez project uses `pytest `_, a Python testing framework, combined with :doc:`a Python wrapper ` around ``octez-node`` and ``octez-client``, to perform integration testing of the node, the client, networks of nodes and daemons such as the baker @@ -197,11 +197,11 @@ Example tests: interpreter (in :src:`tests_python/tests_alpha/test_contract_opcodes.py`). To execute it locally, run ``cd tests_python && poetry run pytest tests/test_contract_opcodes.py`` - in the Tezos root. + in the Octez root. - Setting up networks of nodes and ensuring their connection (in :src:`tests_python/tests_alpha/test_p2p.py`). To execute it locally, run ``cd tests_python && poetry run pytest tests/test_p2p.py`` in - the Tezos root. + the Octez root. References: - `Pytest Documentation `_ @@ -215,7 +215,7 @@ References: Tezt ~~~~ -:doc:`Tezt ` is a system testing framework for Tezos. It is +:doc:`Tezt ` is a system testing framework for Octez. It is intended as a replacement to `Flextesa `_ and as an OCaml-based alternative to :ref:`Python testing and execution framework `. Like the latter, Tezt is also capable of regression @@ -224,8 +224,8 @@ used for some manual tests (see the :src:`tezt/manual_tests` folder). Its main strengths are summarized in its :doc:`section in the Tezos Developer Documentation `. Conceptually Tezt consists of a generic framework for writing tests interacting with external -processes, and a set of Tezos-specific modules for interacting with -the Tezos binaries: the client, baker, etc. +processes, and a set of Octez-specific modules for interacting with +the Octez binaries: the client, baker, etc. Typical use cases: - In terms of use cases, Tezt is similar to the :ref:`Python testing and @@ -242,7 +242,7 @@ Example tests: References: - :doc:`Section in Tezos Developer Documentation on Tezt ` - `General API documentation `_ - - `Tezos-specific API documentation `_ + - `Octez-specific API documentation `_ .. _long_tezt_section: @@ -534,7 +534,7 @@ for doing this depends on the type of test you've added: Python integration and regression tests New Pytest tests will be included automatically in the CI. To rebalance the Pytest batches based on a previous pipeline, - run (from the root of the Tezos repository): + run (from the root of the Octez repository): ``cd tests_python && poetry run python ./scripts/jobs_fetch_reports.py test-results.xml`` setting ```` to a GitLab project id (e.g. ``3836952`` or `tezos/tezos `_) and ```` to the id of a pipeline in this project for which integration tests have executed @@ -543,7 +543,7 @@ Python integration and regression tests Tezt integration and regression tests New Tezt tests will be included automatically in the CI. - To rebalance the Tezt batches, run (from the root of the Tezos repository): + To rebalance the Tezt batches, run (from the root of the Octez repository): ``make && dune exec tezt/tests/main.exe -- --record tezt/test-results.json`` The OCaml package tests (Alcotest & QCheck) @@ -567,7 +567,7 @@ Test coverage in merge requests ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Build and tests are instrumented with ``bisect_ppx`` in the CI for each merge -request on Tezos. To measure test coverage in the CI, it launches the job +request on Octez. To measure test coverage in the CI, it launches the job ``unified_job`` in stage ``test_coverage`` which generates the coverage report. They are stored as an HTML report that can be downloaded or browsed from the CI page upon completion of the job (see the Artifacts produced by the MR pipeline in the GitLab UI). diff --git a/docs/developer/testing_index.rst b/docs/developer/testing_index.rst index 25f63fe19fecf37de9bba8a590fb12b402625304..597817f26de1d8868ca41ec8ef21b1cd69e5a79f 100644 --- a/docs/developer/testing_index.rst +++ b/docs/developer/testing_index.rst @@ -1,11 +1,11 @@ -Testing in Tezos +Testing in Octez ================ -Testing is important to ensure the quality of the Tezos codebase by -detecting bugs and avoiding regressions. Tezos and its +Testing is important to ensure the quality of the Octez codebase by +detecting bugs and avoiding regressions. Octez and its components use a variety of tools and frameworks for testing. -This page groups the documentation helping developers to design, write, and execute tests on the Tezos codebase. +This page groups the documentation helping developers to design, write, and execute tests on the Octez codebase. It covers different kinds of tests (Unit, Integration, etc.) and the associated tools and frameworks. It also includes tutorials for testing more specific parts such as protocol code. diff --git a/docs/developer/tezt.rst b/docs/developer/tezt.rst index 6edf91caa4e572f65716097d7d0c567d2d90ce3d..e87325588592e3eff1a51bf302db86729bc3ec80 100644 --- a/docs/developer/tezt.rst +++ b/docs/developer/tezt.rst @@ -13,7 +13,7 @@ Tezt is pronounced `/tɛzti/ `_ The main benefits of using Tezt-Tezos are: -- tests are written in the same language as Tezos itself (OCaml), +- tests are written in the same language as Octez itself (OCaml), which reduces context switch for developers; - tests do not actively poll the node @@ -62,7 +62,7 @@ How to Write New Integration Tests ---------------------------------- The best way to get started is to have a look at existing tests in directory -``tezt/tests`` of the Tezos repository. +``tezt/tests`` of the Octez repository. Most integration tests are part of the same executable ``tezt/tests/main.exe``. The source of this module is :src:`tezt/tests/main.ml`. diff --git a/docs/developer/time_measurement_ppx.rst b/docs/developer/time_measurement_ppx.rst index 3c975fa0ad693a78b6ab4047051e15338f17a17d..8756db4ff0e5e61ff1f3ddeeb5488822ac769996 100644 --- a/docs/developer/time_measurement_ppx.rst +++ b/docs/developer/time_measurement_ppx.rst @@ -8,7 +8,7 @@ It is able to measure the time spent in the execution of annotated OCaml expressions and to log these measurements when desired. Since it uses ``Tezos_event_logging`` for the logging part, this PPX can easily be used together with ``Tezt`` framework to perform the benchmarking of specific -parts of Tezos node. +parts of Octez node. **This PPX is only intended to be used for tests. As the current runtime implementation performs memory allocation, an unwise usage could mess with diff --git a/docs/introduction/compile-sources.sh b/docs/introduction/compile-sources.sh index 4d91b79e2b14ddb904dea45eee10997bae51230c..e61fd8bccd1dd4b41a6f09c0bf717d776a66b1c8 100755 --- a/docs/introduction/compile-sources.sh +++ b/docs/introduction/compile-sources.sh @@ -49,7 +49,7 @@ chmod +x rustup-init.sh git clone https://gitlab.com/"$REPO".git tezos cd tezos git checkout $BRANCH -# [install Tezos dependencies] +# [install Octez dependencies] opam init --bare make build-deps # [compile sources] diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index 4b01f508613ea70ffc3a87501655a2e0e34b4bdf..a0bf974cdcb3dbb3cffd5e7d383d23f987c706ec 100644 --- a/docs/introduction/howtoget.rst +++ b/docs/introduction/howtoget.rst @@ -6,10 +6,10 @@ How to get Tezos In this how-to we explain how to get up-to-date binaries to run Tezos (more precisely, the "Octez" implementation of Tezos software) on any network (either on the mainnet or on one of the test networks). -Tezos consists of :ref:`several binaries ` (i.e., executable files), including: a client, a node, and a baker. +Octez consists of :ref:`several binaries ` (i.e., executable files), including: a client, a node, and a baker. (Before the :doc:`Ithaca protocol<../protocols/012_ithaca>` it also included an endorser.) -There are several options for getting the binaries, depending on how you plan to use Tezos: +There are several options for getting the binaries, depending on how you plan to use Octez: - :ref:`getting static binaries `. This is the easiest way to get native binaries for the latest stable release, @@ -38,7 +38,7 @@ When choosing between the installation options, you may take into account the convenience of the installation step (and of upgrading steps), but also efficiency and security considerations. For instance, static binaries have a different memory footprint compared to dynamically-linked binaries. Also, -compiling the sources in the official Tezos +compiling the sources in the official Octez repository is more secure than installing OPAM packages from a repository that is not under Tezos control. In particular, compiling from sources enforces a fixed set of dependencies; when compiling via OPAM, this set of dependencies may change, which may or may not be compatible with your security practices. @@ -66,13 +66,13 @@ versions of the binaries. Installing binaries ------------------- -Depending on your operating system, you may install Tezos (dynamically-linked) +Depending on your operating system, you may install Octez (dynamically-linked) binaries and their dependencies using a package manager, as follows. -Ubuntu Launchpad PPA with Tezos packages +Ubuntu Launchpad PPA with Octez packages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If you're using Ubuntu, you can install packages with Tezos binaries from a Launchpad PPA. +If you're using Ubuntu, you can install packages with Octez binaries from a Launchpad PPA. Currently it supports Focal and Bionic versions. In order to add the stable release PPA repository to your machine, do: @@ -100,13 +100,13 @@ Upgrading to a newer release is made easy by the APT package manager, using commands such as ``apt-get update``, ``apt-get upgrade ``, and ``apt-get install ``. Indeed, as the names of some packages (e.g. the baker) depend on their version, you may have to also install new packages. -You may take a look at the available packages in the Tezos PPA repository listed +You may take a look at the available packages in the Octez PPA repository listed by ``apt-get update``. -Fedora Copr repository with Tezos packages +Fedora Copr repository with Octez packages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If you're using Fedora, you can install packages with Tezos binaries from a Copr repository. +If you're using Fedora, you can install packages with Octez binaries from a Copr repository. Currently it supports Fedora 35. In order to add the stable Copr repository to your machine, do: @@ -134,7 +134,7 @@ Upgrading to a newer release is made easy by the DNF package manager, using commands such as ``dnf upgrade ``, and ``dnf install ``. Indeed, as the names of some packages (e.g. the baker) depend on their version, you may have to also install new packages. -You may take a look at the available packages in the Tezos Copr repository +You may take a look at the available packages in the Octez Copr repository listed by ``dnf repoinfo``. .. _using_docker_images: @@ -238,7 +238,7 @@ source package manager for OCaml. This is easier than :ref:`setting up a complete development environment `, like developers do. However, this method is recommended for expert users as it requires basic knowledge of the OPAM package manager and the OCaml packages -workflow. In particular, upgrading Tezos from release to +workflow. In particular, upgrading Octez from release to release might require tinkering with different options of the OPAM package manager to adjust the local environment for the new dependencies. @@ -249,7 +249,7 @@ dependencies. Environment ~~~~~~~~~~~ -Currently Tezos is being developed for Linux x86_64, mostly for +Currently Octez is being developed for Linux x86_64, mostly for Debian/Ubuntu and Arch Linux. The following OSes are also reported to work: macOS (x86_64), Arch Linux ARM (aarch64), Debian Linux (buster), Ubuntu Linux (focal). A Windows port is feasible and might be @@ -274,10 +274,10 @@ the next step. .. _install_opam_packages: -Install Tezos OPAM packages +Install Octez OPAM packages ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The latest Tezos release is available (as soon as possible after the +The latest Octez release is available (as soon as possible after the release) directly as OPAM packages. .. note:: @@ -392,7 +392,7 @@ Identified situations where it will be more tricky are: Setting up the development environment from scratch --------------------------------------------------- -If you plan to contribute to the Tezos codebase, the way to go is to set up a +If you plan to contribute to the Octez codebase, the way to go is to set up a complete development environment, by cloning the repository and compiling the sources using the provided makefile. @@ -438,7 +438,7 @@ The following sections describe the individual steps above in more detail. Install Rust ~~~~~~~~~~~~ -Compiling Tezos requires the Rust compiler (see recommended version in variable +Compiling Octez requires the Rust compiler (see recommended version in variable ``$recommended_rust_version`` in file ``scripts/version.sh``) and the Cargo package manager to be installed. If you have `rustup `_ installed, it should work without any @@ -472,10 +472,10 @@ if file ``.cargo`` does not exist in your home directory. Install Zcash Parameters ~~~~~~~~~~~~~~~~~~~~~~~~ -Tezos binaries require the Zcash parameter files to run. +Octez binaries require the Zcash parameter files to run. Docker images come with those files, and the source distribution also -includes those files. But if you compile from source and move Tezos to -another location (such as ``/usr/local/bin``), the Tezos binaries may +includes those files. But if you compile from source and move Octez to +another location (such as ``/usr/local/bin``), the Octez binaries may prompt you to install the Zcash parameter files. The easiest way is to download and run this script:: @@ -516,7 +516,7 @@ Note that the script ``fetch-params.sh`` downloads a third file containing param Get the sources ~~~~~~~~~~~~~~~ -Tezos ``git`` repository is hosted at `GitLab +Octez ``git`` repository is hosted at `GitLab `_. All development happens here. Do **not** use our `GitHub mirror `_ which we don't use anymore and only mirrors what happens on GitLab. @@ -524,10 +524,10 @@ which we don't use anymore and only mirrors what happens on GitLab. Checkout the ``latest-release`` branch to use the latest release. Alternatively, you can checkout a specific version based on its tag. -Install Tezos dependencies +Install Octez dependencies ~~~~~~~~~~~~~~~~~~~~~~~~~~ -Install the OCaml compiler and the libraries that Tezos depends on:: +Install the OCaml compiler and the libraries that Octez depends on:: make build-deps @@ -542,7 +542,7 @@ command instead: .. note:: * These commands create a local OPAM switch (``_opam`` folder at the root - of the repository) where the required version of OCaml and OCaml Tezos + of the repository) where the required version of OCaml and OCaml Octez dependencies are compiled and installed (this takes a while but it's only done once). @@ -572,7 +572,7 @@ refer to the new switch and compile the project: :start-after: [compile sources] :end-before: [optional setup] -Lastly, you can also add the Tezos binaries to your ``PATH`` variable, +Lastly, you can also add the Octez binaries to your ``PATH`` variable, and after reading the Disclaimer a few hundred times you are allowed to disable it with ``TEZOS_CLIENT_UNSAFE_DISABLE_DISCLAIMER=Y``. diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index 8b1290af3baed6a326ff55535dd46368fb08102f..d197deee9624179119ae30a27e1ee15ea5bc7645 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -1,6 +1,6 @@ .. TODO tezos/tezos#2170: search shifted protocol name/number & adapt -How to run Tezos +How to run Octez ================ In this section, we discuss how to take part in the protocol that runs @@ -12,7 +12,7 @@ The second way allows to participate more actively in the protocol, by baking bl To learn more about the protocol refer to :doc:`this page <../active/protocol_overview>`. -No matter how you decide to run Tezos, your node must have an accurate time source and be properly synchronized to it, e.g. by configuring an NTP daemon. +No matter how you decide to run Octez, your node must have an accurate time source and be properly synchronized to it, e.g. by configuring an NTP daemon. This is especially important for bakers, as baking nodes desynchronized from the correct time of day have caused operational problems in the past by "baking in the future". .. _delegating_coins: diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index d357e0fe8f281f9853686614dbd83a2c47840b50..b2b5911d9093d87a77c48c8991b4dbbbe64b7122 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -2,10 +2,10 @@ .. _howtouse: -Getting started with Tezos +Getting started with Octez ========================== -This short tutorial illustrates the use of the various Tezos binaries as well +This short tutorial illustrates the use of the various Octez binaries as well as some concepts about the network. .. _tezos_binaries: @@ -15,7 +15,7 @@ The Binaries After a successful compilation, you should have the following binaries: -- ``octez-node``: the tezos daemon itself (see `Node`_); +- ``octez-node``: the Octez daemon itself (see `Node`_); - ``octez-client``: a command-line client and basic wallet (see `Client`_); - ``octez-admin-client``: administration tool for the node (see :ref:`octez-admin-client`); - ``octez-{baker,accuser}-*``: daemons to bake and accuse on the Tezos network (see :doc:`howtorun`); @@ -406,7 +406,7 @@ more costs being added on top of the transfer and the burn: `fees`. To encourage a baker to include our operation, and in general to pay for the cost of running the blockchain, each operation usually includes a fee that goes to the baker. -Fees are variable over time and depend on many factors but the tezos +Fees are variable over time and depend on many factors but the Octez client selects a default for us. The last important bit of our receipt is the balance updates that @@ -647,7 +647,7 @@ In this short tutorial we will not use some other binaries, but let as briefly r Codec ~~~~~ -The Tezos codec (``octez-codec``) is a utility that: +The Octez codec (``octez-codec``) is a utility that: - provides documentation for all the encodings used in the ``octez-node`` (and other binaries), and - allows to convert from JSON to binary and vice-versa for all these encodings. @@ -665,15 +665,15 @@ It is meant to be used: - by developers to compile the protocol under development, - by the packaging process to compile protocols that are pre-linked in the binaries, -- by the Tezos node when there is an on-chain update to a protocol that is not pre-linked with the binary. +- by the Octez node when there is an on-chain update to a protocol that is not pre-linked with the binary. Summary ------- In this tutorial, you have learned: -- to start a Tezos node and set up its basic configuration; -- to use the Tezos client to create implicit accounts and do transfers between them; +- to start an Octez node and set up its basic configuration; +- to use the Octez client to create implicit accounts and do transfers between them; - to deploy and interact with a simple predefined smart contract; - to distinguish between the various costs associated to transactions such as burnt tez, fees, storage costs, and gas consumption; - some further concepts such as transaction validation and the RPC interface; diff --git a/docs/lima/sapling.rst b/docs/lima/sapling.rst index 0cbf62103edc51a8a2b4809a887e06fdad53abc2..5bfe6920339d847682560a4995ecc3214c6ebe17 100644 --- a/docs/lima/sapling.rst +++ b/docs/lima/sapling.rst @@ -12,10 +12,10 @@ paper `_. The reference implementation of Sapling, `librustzcash `_, was -integrated in the Tezos codebase during 2019. It will be proposed as +integrated in the Octez codebase during 2019. It will be proposed as part of a protocol amendment during 2020. -Librustzcash and the Tezos integration implement the protocol +Librustzcash and the Octez integration implement the protocol described in this `specification `_, version 2020.1.0. @@ -442,7 +442,7 @@ Client Under `lib_client_sapling` there is the client integration with the support for Sapling keys and forging of transactions. -The main difference from the existing Tezos client is the need for the +The main difference from the existing Octez client is the need for the Sapling client to keep an additional state, for each contract. Because Sapling uses a UTXO model it is necessary for a client to compute the set of unspent outputs in order to forge new transactions. diff --git a/docs/lima/validation.rst b/docs/lima/validation.rst index 85d3431f86f7b61f776ebc1be17997ab5b51fc61..66cb14ca9e59028f565c93ad265cbbff537bc008 100644 --- a/docs/lima/validation.rst +++ b/docs/lima/validation.rst @@ -80,12 +80,12 @@ Validation modes ================ The Tezos protocol provides different validation modes, intended to be -used by Tezos *shell* and *baker* software implementations when +used by the Tezos *shell* and *baker* software implementations when needing to apply (or to assert the validity) of blocks and operations under different, or specialized, circumstances -- for example, in order to *bake* a block. For each of these validation modes, the API specified by the protocol environment offers an entry-point so that -protocol agnostic components, the Octez shell for instance, are able +protocol agnostic components, the Tezos shell for instance, are able to use these different modes. .. _full_application: diff --git a/docs/lima/voting.rst b/docs/lima/voting.rst index 92a13cc6d029af91924619f6af926c26b93a77db..6dee1140cc1310d9044997c1676eee13f21f8da0 100644 --- a/docs/lima/voting.rst +++ b/docs/lima/voting.rst @@ -258,7 +258,7 @@ interaction with the amendment and voting process. Show ~~~~ -Tezos' client provides a command to show the status of a voting period. +The client provides a command to show the status of a voting period. It displays different information for different kind of periods, as in the following samples:: diff --git a/docs/mumbai/sapling.rst b/docs/mumbai/sapling.rst index e5122eae92288714bb909bf8fbb63da987db5410..28f7bb4d9dd048db9ac49ad6363cc65c5228cfb3 100644 --- a/docs/mumbai/sapling.rst +++ b/docs/mumbai/sapling.rst @@ -12,10 +12,10 @@ paper `_. The reference implementation of Sapling, `librustzcash `_, was -integrated in the Tezos codebase during 2019. It will be proposed as +integrated in the Octez codebase during 2019. It will be proposed as part of a protocol amendment during 2020. -Librustzcash and the Tezos integration implement the protocol +Librustzcash and the Octez integration implement the protocol described in this `specification `_, version 2020.1.0. @@ -442,7 +442,7 @@ Client Under `lib_client_sapling` there is the client integration with the support for Sapling keys and forging of transactions. -The main difference from the existing Tezos client is the need for the +The main difference from the existing Octez client is the need for the Sapling client to keep an additional state, for each contract. Because Sapling uses a UTXO model it is necessary for a client to compute the set of unspent outputs in order to forge new transactions. diff --git a/docs/mumbai/smart_rollups.rst b/docs/mumbai/smart_rollups.rst index cdd1821ca36a8e28922559bbc9cf0114d8d6e28b..319f297a5e2d3bce5dd2a5981daffaa638b63006 100644 --- a/docs/mumbai/smart_rollups.rst +++ b/docs/mumbai/smart_rollups.rst @@ -288,7 +288,7 @@ docker images or can be compiled from sources. Please refer to the `Mondaynet `_ website for installation details. -An Octez rollup node needs an Octez tezos node to run. We assume that +An Octez rollup node needs an Octez node to run. We assume that a rollup node has been launched locally, typically by issuing: .. code:: sh diff --git a/docs/mumbai/validation.rst b/docs/mumbai/validation.rst index 9908925b0aff4d67da10fc406bc5d4beaeea6ed3..ef7300ddd232f918e968ea8b0eb2b57e8b90b428 100644 --- a/docs/mumbai/validation.rst +++ b/docs/mumbai/validation.rst @@ -80,12 +80,12 @@ Validation modes ================ The Tezos protocol provides different validation modes, intended to be -used by Tezos *shell* and *baker* software implementations when +used by the Tezos *shell* and *baker* software implementations when needing to apply (or to assert the validity) of blocks and operations under different, or specialized, circumstances -- for example, in order to *bake* a block. For each of these validation modes, the API specified by the protocol environment offers an entry point so that -protocol-agnostic components, the Octez shell for instance, are able +protocol-agnostic components, the Tezos shell for instance, are able to use these different modes. .. _full_application_mumbai: diff --git a/docs/mumbai/voting.rst b/docs/mumbai/voting.rst index 22fdd626929d8d13b976aca6dd45ee54a60edd76..970826d5ba0069aeffeeada1cf84e9707ea905c8 100644 --- a/docs/mumbai/voting.rst +++ b/docs/mumbai/voting.rst @@ -258,7 +258,7 @@ interaction with the amendment and voting process. Show ~~~~ -Tezos' client provides a command to show the status of a voting period. +The client provides a command to show the status of a voting period. It displays different information for different kind of periods, as in the following samples:: diff --git a/docs/protocols/alpha.rst b/docs/protocols/alpha.rst index a03c82afe37e62f9ca53bc40c750fc44ef0708a7..15336c174fcba821a68b490aeb58ff1c5c70a120 100644 --- a/docs/protocols/alpha.rst +++ b/docs/protocols/alpha.rst @@ -5,7 +5,7 @@ This page documents the changes brought by protocol Alpha with respect to Mumbai (see :ref:`naming_convention`). The code can be found in directory :src:`src/proto_alpha` of the ``master`` -branch of Tezos. +branch of Octez. .. contents:: diff --git a/docs/releases/releases.rst b/docs/releases/releases.rst index bb1102bfb0a24321af952fd2d737e9932d51ac0c..1a8962e6421ed76d1515e7c717e3e5b76cb8afbc 100644 --- a/docs/releases/releases.rst +++ b/docs/releases/releases.rst @@ -48,7 +48,7 @@ suffixed by ``~rc``. Releases are available in several forms: -- in source form, from the Tezos code repository +- in source form, from the Octez code repository (https://gitlab.com/tezos/tezos). Tags for each release are available prefixed by ``v``, and there is also a ``latest-release`` tag, pointing to the latest **stable release** (i.e., excluding release candidates). @@ -83,5 +83,5 @@ The packaged forms are updated from the source form as follows: - The process is currently performed manually by `Serokell `_. -For installing Tezos from these different forms of releases, see +For installing Octez from these different forms of releases, see :doc:`../introduction/howtoget`. diff --git a/docs/scripts/test_doc_scripts.sh b/docs/scripts/test_doc_scripts.sh index 262fae40f2d06bbee7ae81bf98c1501ee878bd89..fc94f09e4b4b6602ad34492e480c67d8fda0b723 100755 --- a/docs/scripts/test_doc_scripts.sh +++ b/docs/scripts/test_doc_scripts.sh @@ -1,5 +1,5 @@ #!/usr/bin/env bash -# Test the different Tezos installation scenarios documented in howtoget.rst. +# Test the different Octez installation scenarios documented in howtoget.rst. # # The scenarios are implemented by separate scripts, which are both: # - called by this script within the appropriate Docker containers, and diff --git a/docs/shell/cli-commands.rst b/docs/shell/cli-commands.rst index 33c6bf657954437305bd405332cb0b6c0941b655..9553aae6c6baf072a65b47845314c800ed5d045a 100644 --- a/docs/shell/cli-commands.rst +++ b/docs/shell/cli-commands.rst @@ -3,7 +3,7 @@ Command Line Interface ********************** This document is a prettier output of the documentation produced by -the command ``man`` of the different Tezos binaries. You can +the command ``man`` of the different Octez binaries. You can obtain similar pages using shell commands such as: :: @@ -55,7 +55,7 @@ Codec manual Node manual =========== -The command line of the Tezos node is not currently documented as an HTML page, but rather in Unix manual format. You can also obtain it by running ``octez-node --help``, which gives the manual below. +The command line of the Octez node is not currently documented as an HTML page, but rather in Unix manual format. You can also obtain it by running ``octez-node --help``, which gives the manual below. This manual briefly shows the available node commands. Each command accepts its own set of options and arguments, that you can discover by running ``octez-node --help``. For more details on the node invocation and configuration, see see :doc:`../user/node-configuration`. diff --git a/docs/shell/micheline.rst b/docs/shell/micheline.rst index 2196615cf59c8b3a700027886759d7d76e978094..5e85310f129c628012fe799a0cc14c56175e28df 100644 --- a/docs/shell/micheline.rst +++ b/docs/shell/micheline.rst @@ -218,8 +218,8 @@ primitives of the Alpha protocol can be generated by the command Usage of the OCaml Micheline library ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In the Tezos codebase, Micheline nodes are handled by a small library -named ``lib_micheline``. This library is used in the Tezos client +In the Octez codebase, Micheline nodes are handled by a small library +named ``lib_micheline``. This library is used in the Octez client (responsible for parsing the Michelson files, expanding macros, and encoding the result to JSON) and in the Tezos protocol (responsible for decoding from JSON, type checking, and serializing to binary @@ -290,7 +290,7 @@ by semicolons. They both take an optional boolean parameter named Other tools and resources ------------------------- -The following links are not part of the Tezos OCaml code base but are +The following links are not part of the Octez OCaml code base but are reimplementations of parts of ``lib_micheline`` in other tools and languages: diff --git a/docs/shell/rpc_introduction.rst.inc b/docs/shell/rpc_introduction.rst.inc index 93abbd5534b8199bef1dcd16a144ab6c63c6c4a1..3e0e2421fd3f45ca3764cce64124f7e8bb3a3ec6 100644 --- a/docs/shell/rpc_introduction.rst.inc +++ b/docs/shell/rpc_introduction.rst.inc @@ -1,4 +1,4 @@ -This page describes the RPCs built into the Octez shell, which are independent from a particular version of the Tezos protocol. +This page describes the RPCs built into the Tezos shell, which are independent from a particular version of the Tezos protocol. .. warning:: diff --git a/docs/shell/the_big_picture.rst b/docs/shell/the_big_picture.rst index 69320973c1dd69b47e83e736b64914dbf66b8328..d4adbb59d7c5e007b346095656f56042a174247f 100644 --- a/docs/shell/the_big_picture.rst +++ b/docs/shell/the_big_picture.rst @@ -214,7 +214,7 @@ protocol in an alternative environment possible. The Embedded Economic Protocols ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Three kinds of economic protocols are included in the main Tezos repository. +Three kinds of economic protocols are included in the main Octez repository. - The genesis protocol. :package:`tezos-protocol-genesis` (:package:`tezos-embedded-protocol-genesis`) is the protocol of diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index ceb0becbadba33c72a6e277dac865985a1502916..51dc207f5f37241483d202efab6c7ae8516afda6 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -293,11 +293,11 @@ The operation is signed by the manager key and does not require the consensus pr However the public key must be known by the client. It can be imported with the command:: - tezos-client import public key consensus unencrypted:edpk... + octez-client import public key consensus unencrypted:edpk... The command to update the consensus key is:: - tezos-client set consensus key for to consensus + octez-client set consensus key for to consensus The update becomes active after ``PRESERVED_CYCLES + 1`` cycles. We therefore distinguish the active consensus key and the pending consensus keys. @@ -305,7 +305,7 @@ The active consensus key is by default the delegate’s manager key, which canno However, it is also possible to register as a delegate and immediately set the consensus key:: - tezos-client register key as delegate with consensus key + octez-client register key as delegate with consensus key There can be multiple pending updates: it is possible to have multiple pending consensus keys for multiple future cycles. A subsequent update within the same cycle takes precedences over the initial one. @@ -315,23 +315,23 @@ Baking With a Consensus Key In your baker's command, replace the delegate's manager key alias with the consenus key alias:: - tezos-baker-0XX-Psxxxxxx run with local node ~/.tezos-node --liquidity-baking-toggle-vote pass + octez-baker-Ptxxxxxx run with local node ~/.tezos-node --liquidity-baking-toggle-vote pass While transitioning from the delegate's manager key, it is possible to pass the alias for both delegate's manager key and consensus key. The delegate will seamlessly keep baking when the transition happens:: - tezos-baker-0XX-Psxxxxxx run with local node ~/.tezos-node --liquidity-baking-toggle-vote pass + octez-baker-Ptxxxxxx run with local node ~/.tezos-node --liquidity-baking-toggle-vote pass Draining a Manager's Account With its Consensus Key ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This operation immediately transfers all the spendable balance of the ``baker_pkh``’s implicit account into the ``destination_pkh`` implicit account:: - tezos-client drain delegate to with + octez-client drain delegate to with If the destination is the consensus key account, this can be simplified to:: - tezos-client drain delegate to + octez-client drain delegate to The active consensus key is the signer for this operation, therefore the private key associated to the consensus key must be available in the wallet of the client typing the command. The delegate's private key does not need to be present. diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst index 107e2efc7f768444910c0d37b9f240aeb8c96c03..afe37bc843968f6d5e784a39625fb4bbb4fd3380 100644 --- a/docs/user/node-configuration.rst +++ b/docs/user/node-configuration.rst @@ -1,7 +1,7 @@ Node Configuration ================== -The Tezos node can be configured in flexible ways to control various +The Octez node can be configured in flexible ways to control various aspects of its behavior, such as :ref:`RPC `, :ref:`P2P `, or :ref:`shell ` parameters, the directory for storing data, :doc:`logging <./logging>`, and so on. These aspects diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst index e87a35cca08490bf5cc52e5360191b8538f1db26..8f8dfdd2416a05f5141a001dbf66e072c1f262c4 100644 --- a/docs/user/snapshots.rst +++ b/docs/user/snapshots.rst @@ -43,7 +43,7 @@ and predecessor, as well as the resulting chain state. The import process does the same checks, recomputing and checking all the hashes it encounters in the snapshot. -To bootstrap a Tezos node from a file to an empty Tezos +To bootstrap an Octez node from a file to an empty Tezos node directory (running this command from an already synchronised node will not work), run: diff --git a/docs/user/various.rst b/docs/user/various.rst index 02c0497377127cbaae9bb82bea1e52bfe40fde9a..0826b91a40214078f419c51d378875084e34e19d 100644 --- a/docs/user/various.rst +++ b/docs/user/various.rst @@ -28,7 +28,7 @@ A useful command to debug a node that is not syncing is: .. _tezos_binaries_signals_and_exit_codes: -Tezos binaries: signals and exit codes +Octez binaries: signals and exit codes -------------------------------------- Signals: