diff --git a/.gitlab/ci/doc.yml b/.gitlab/ci/doc.yml index 52d3f32ace6f31a5a46feb78491112ba95287fbd..a9c6b6bdb3b172376c2e59ef91b09086677583a2 100644 --- a/.gitlab/ci/doc.yml +++ b/.gitlab/ci/doc.yml @@ -62,10 +62,6 @@ publish:documentation: # Give access to the Python dependencies/executables - . $HOME/.venv/bin/activate script: - - echo "$CI_SERVER_URL/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/" - - echo "$CI_COMMIT_REF_NAME" - - echo "$CI_PROJECT_URL" - - echo "$CI_MERGE_REQUEST_SOURCE_PROJECT_URL" - if [ "${CI_COMMIT_REF_NAME}" == "master" ] ; then make -C docs full ; git clone --depth 5 git@gitlab.com:${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAMESPACE}.gitlab.io gitlab.io ; diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst index 675448c6cfe45143e6078288d2b18210b7d45429..6d2854b1449b7035210154467906768483d850fa 100644 --- a/docs/alpha/consensus.rst +++ b/docs/alpha/consensus.rst @@ -179,9 +179,9 @@ not the other way around.): - ``spendable balance`` is obtained with ``../context/contracts//balance`` Delegates can set an upper limit to their frozen deposits with the -commands ``tezos-client set deposit limit for to +command ``tezos-client set deposits limit for to ``, and unset this limit with the command ``tezos-client -unset deposit limit for ``. These commands are implemented by +unset deposits limit for ``. These commands are implemented using a new manager operation ``Set_deposits_limit``. When emitting such a command in cycle ``c``, it affects the active stake for cycles starting with ``c + PRESERVED_CYCLES + 1``; the new active stake is diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst index b99948d0a10b44972b1bc323b72f92c5fb49d8fd..f61d1e1e1b21f6eb009d0a34f74ff2e2707f060f 100644 --- a/docs/developer/contributing.rst +++ b/docs/developer/contributing.rst @@ -29,11 +29,15 @@ Going further ~~~~~~~~~~~~~ You may also want to fix some typos and minor errors or incoherencies in the *documentation*, which is situated in the ``docs/`` subfolder of the code repository. -This kind of small contributions can be done without creating a merge request, by directly pushing commits to the ``typo-doc`` branch, which is regularly merged into the master branch, e.g., every one or two weeks. +Small tweaks like these can be contributed without creating a merge request and commits can rather be pushed directly to the ``typo-doc`` branch in the ``tezos/tezos`` repository. This branch is regularly merged into the master branch, e.g., every one or two weeks. +(If the branch has been automatically deleted following a merge, just create it again.) This periodic merging is implemented by a series of MRs named "the typo train", created for you by a volunteer, and batching the currently pending fixes. Of course, all these commits will be reviewed before being integrated. The current edition of the typo train MR can be found in meta-issue :gl:`#2329`. +If you don't have enough permissions to push to the branch above, you can still make commits in your own fork of the Octez repository, and ask for them to be cherry-picked on the typo/train on the ``#documentation`` channel on the Tezos Dev Slack space. +Alternatively, you may of course create your own MRs for submitting your changes, without using the typo train. + To directly contribute to the *codebase*, expertise in a few areas is necessary. First, make sure that you are proficient enough in OCaml. The community @@ -119,32 +123,29 @@ While the code is still not ready to be peer reviewed, but it is merely a work in progress, the developer prefixes the MR with ``Draft:`` and assigns it to themselves. This will tell everybody they can look at the code, comment, but there is still work to be done -and the branch can change and history be rewritten. Alternatively, the -MR title can be prefixed with ``WIP:``. ``Draft:`` prefix is -sometimes set automatically by GitLab, so ``WIP:`` is in a sense less -ambiguous. +and the branch can change and history be rewritten. Finally, when the code is ready for the :ref:`code review -`, the developer removes the Draft status (or ``WIP:`` -prefix) of the MR and freezes the branch. From this moment on, the -developer will refrain from rewriting history, but he/she can add new +`, the developer removes the Draft status +of the MR and freezes the branch. From this moment on, the +developer will refrain from rewriting history, but they can add new commits and rebase the branch for syncing it with master (this can be done regularly to make sure the branch does not get stale). At this point the developer interacts with the reviewers to address their comments and suggestions. GitLab allows both to comment on the code and to add general comments -on the MR. Each comment should be addressed by the developer. He/she +on the MR. Each comment should be addressed by the developer. They can add additional commits to address each comment. This incremental approach will make it easier for the reviewer to keep interacting till -each discussion is resolved. When the reviewer is satisfied, he/she +each discussion is resolved. When the reviewer is satisfied, they will mark the discussion resolved. When all discussions are resolved, and the MR has got at least two approvals from Octez Merge Team members, the developer should squash any fix-up commits that were applied (remembering to edit the commit message appropriately). Then anyone can assign the MR to the `Nomadic -Margebot `__, which will +Marge-bot `__, which will automatically rebase the branch on top of master and finally merge it. .. _preparing_MR: @@ -165,7 +166,7 @@ While working on your branch to prepare a Merge Request, make sure you respect t the branch name. + Use ``opam`` in the branch name if you want to explicitly trigger - the OPAM packaging pipeline. Note that any OPAM related changes + the opam packaging pipeline. Note that any opam related changes will automatically trigger it. + Use ``doc`` in the branch name if you change the documentation. + Use ``arm64`` in the branch name if you need to build ARM64 artifacts. @@ -194,8 +195,8 @@ While working on your branch to prepare a Merge Request, make sure you respect t non-obvious design choice), you should document them in this file header, but in a separate "History" section. - If you add new functions to an interface, don’t forget to - document the function in the interface (in the corresponding .mli file; or, - if there is no .mli file, directly in the .ml file) + document the function in the interface (in the corresponding ``.mli`` file; or, + if there is no ``.mli`` file, directly in the ``.ml`` file) - If you add a new RPC endpoint or modify an existing one, be sure to take into account the impact on :ref:`RPC security `. - If you modify the user API (e.g. add or change a configuration parameter or @@ -289,7 +290,7 @@ Therefore, when creating your MR, observe the following rules: + ``ci--opam`` is for triggering the opam packaging tests pipeline. + ``ci--docs`` is for testing some scripts in the documentation (e.g. Octez installation scenarios). - + ``ci--docker`` is for publishing the docker image of the MR. + + ``ci--docker`` is for publishing the Docker image of the MR. + ``ci--arm64`` is for building on the ARM64 architecture. - *MR Options*: When opening an MR you should probably tick the following @@ -397,7 +398,7 @@ action is required to get the merge request moving. Example actions include: - merge; - find someone else who can get the merge request moving. -The assignee will thus often be one of the reviewers (if he needs to review +The assignee will thus often be one of the reviewers (if they needs to review or respond to a comment) or one of the merge request authors (if they need to update the code or respond to a comment). @@ -425,7 +426,7 @@ To find reviewers, either: - Look at authors of the code you are modifying using `git blame `_. - Ask help to the :ref:`merge coordinator `, either - by asking him/her on Slack or mentioning them in a comment (see next paragraph). + by asking them on Slack or mentioning them in a comment (see next paragraph). Depending on your `GitLab role `_ you may or may not be able to use the *Reviewers* field for specifying @@ -479,14 +480,14 @@ this additional dedicated guide: contributing-adding-a-new-opam-dependency -In the special case where your MR adds a new Python, Rust, Javascript, or other +In the special case where your MR adds a new Python, Rust, JavaScript, or other dependency, additional steps must also be followed. * for Python, you can refer to the related section in the :ref:`python testing documentation `. * the Rust dependencies are located in the GitLab repository `tezos-rust-libs `_ and the instructions are listed there. For others, there is currently no dedicated guide. Do not hesitate to ask for -help on the ``#devteam`` channel on the `tezos-dev` Slack. +help on the ``#devteam`` channel on the `tezos-dev `_ Slack. .. _protocol_mr: @@ -534,7 +535,7 @@ Merge Request Approvals ~~~~~~~~~~~~~~~~~~~~~~~ Two approvals from different Octez :doc:`Octez merge team ` members are required for merge -requests to be merged. Both approvals must result from independent thorough +requests to be merged. Both approvals must result from independent, thorough reviews. After both reviews, the second approver will also typically merge. However, for less critical parts of the code, an Octez merge team member may @@ -567,7 +568,7 @@ painful for everybody. The reviewer is your ally, not your enemy. Did I leave a :ref:`TODO/FIXME comment ` without an issue number? - Docstrings: Did I export a new function? Each exported - function should be documented in the corresponding ``mli`` (or directly in the ``ml`` file if there is no ``mli``). + function should be documented in the corresponding ``.mli`` (or directly in the ``.ml`` file if there is no ``.mli``). - README: Did I check whether my changes impact the corresponding README file(s)? @@ -647,7 +648,7 @@ pitfalls a code reviewer should avoid. have a different reaction to it and impact on the quality of this work. This general remark is valid for any comment. -When reviewing MRs involving documentation, you may check the built documentation directly within the Gitlab interface, see :ref:`build_doc_ci`. +When reviewing MRs involving documentation, you may check the built documentation directly within the GitLab interface, see :ref:`build_doc_ci`. .. _merge_bot: diff --git a/docs/developer/merge_team.rst b/docs/developer/merge_team.rst index b4d0f556ef3a65453bee66479737ff6d9a7eda14..b0fa49d868151f0809d2f99546433301ca058e05 100644 --- a/docs/developer/merge_team.rst +++ b/docs/developer/merge_team.rst @@ -22,7 +22,7 @@ the next protocol (``src/proto_alpha/lib_protocol/``). Companies that contribute `tezos/tezos `_ reach a consensus to decide what gets in the Alpha protocol, i.e. in the proposal of the next upgrade. In particular, other companies -can fork this repo and do their own protocol proposals. +can fork this repository and do their own protocol proposals. .. _merge_coordinator: @@ -79,8 +79,8 @@ The Octez merge team is always looking for software engineers with at least the - You are relatively skilled in one of the technologies used in the ``tezos/tezos`` repository, i.e. ``OCaml``, ``python``, ``CI``, building, packaging, etc. -To apply for being included in the Octez merge team, contact an existing member -on the `tezos-dev `_ Slack. Your application +To apply for being included in the Octez merge team, contact the :ref:`merge coordinator ` or +an existing member on the `tezos-dev `_ Slack. Your application will be discussed during the next weekly meeting of the Octez merge team. Helping the Octez Merge Team diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index 97afc6c0ced9fc0e61ccd82d1fb29c63e7496a6f..978771c91d3a27ee2a8af562a51c0d40b7bb9793 100644 --- a/docs/introduction/howtoget.rst +++ b/docs/introduction/howtoget.rst @@ -476,6 +476,8 @@ and ``sapling-output.params``. Here is where you should expect to find those fil Some operating systems may not be covered by the list of directories above. If Zcash is located elsewhere on your system (typically, on MacOS X), you may try creating a symbolic link such as: ``ln -s ~/Library/Application\ Support/ZcashParams ~/.zcash-params``. +Note that the script ``fetch-params.sh`` downloads a third file containing parameters for Sprout (currently called ``sprout-groth16.params``), which is not loaded by Sapling and can be deleted to save a significant amount of space (this file is *much* bigger than the two other files). + Get the sources ~~~~~~~~~~~~~~~ diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index f7a04d62e307ba6e5d307128e07e24d64d379f24..c9d41576c7f58e4ebdcb3a382bb83e160c90fdca 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -126,7 +126,7 @@ connect to the network:: .. note:: If the node prompts you to install the Zcash parameter file, follow - the :ref`corresponding instructions `. + the :ref:`corresponding instructions `. The identity comprises a pair of cryptographic keys that nodes use to encrypt messages sent to each other, and an diff --git a/docs/ithaca/consensus.rst b/docs/ithaca/consensus.rst index e0b0ee53fcf9dd0c787389fa6a29f116a6f3d922..574bc84624fa50750835d1b34fd1a15831e6f437 100644 --- a/docs/ithaca/consensus.rst +++ b/docs/ithaca/consensus.rst @@ -185,9 +185,9 @@ not the other way around.): - ``spendable balance`` is obtained with ``../context/contracts//balance`` Delegates can set an upper limit to their frozen deposits with the -commands ``tezos-client set deposit limit for to +command ``tezos-client set deposits limit for to ``, and unset this limit with the command ``tezos-client -unset deposit limit for ``. These commands are implemented by +unset deposits limit for ``. These commands are implemented using a new manager operation ``Set_deposits_limit``. When emitting such a command in cycle ``c``, it affects the active stake for cycles starting with ``c + PRESERVED_CYCLES + 1``; the new active stake is diff --git a/docs/jakarta/consensus.rst b/docs/jakarta/consensus.rst index 1148a65401571d3000285152e9603a3e2c860790..336c3ca3c35c489bb40f37aa35a3b704f1e209d2 100644 --- a/docs/jakarta/consensus.rst +++ b/docs/jakarta/consensus.rst @@ -179,9 +179,9 @@ not the other way around.): - ``spendable balance`` is obtained with ``../context/contracts//balance`` Delegates can set an upper limit to their frozen deposits with the -commands ``tezos-client set deposit limit for to +command ``tezos-client set deposits limit for to ``, and unset this limit with the command ``tezos-client -unset deposit limit for ``. These commands are implemented by +unset deposits limit for ``. These commands are implemented using a new manager operation ``Set_deposits_limit``. When emitting such a command in cycle ``c``, it affects the active stake for cycles starting with ``c + PRESERVED_CYCLES + 1``; the new active stake is diff --git a/docs/shell/cli-commands.rst b/docs/shell/cli-commands.rst index 7d32fc880077eff87f12073d498ae8ab2e243409..2e63c317b52d238253cc1a634e6a78b42a35d1e9 100644 --- a/docs/shell/cli-commands.rst +++ b/docs/shell/cli-commands.rst @@ -59,3 +59,6 @@ The command line of the Tezos node is not currently documented as a web page, bu you can obtain it in Unix manual format by running the node with no arguments:: tezos-node + +The above command briefly shows the available node commands. +Each command accepts its own set of options and arguments, see :doc:`../user/node-configuration`. diff --git a/docs/shell/prevalidation.rst b/docs/shell/prevalidation.rst index 210c31ab625e83c20a9a97cf0939d5d47841193c..a98382e6000a5b1875327f9ed9b71f6f28249a9c 100644 --- a/docs/shell/prevalidation.rst +++ b/docs/shell/prevalidation.rst @@ -65,7 +65,7 @@ applied, then the operation is propagated over the gossip network. Currently, the ``precheck`` filter is only implemented for manager operations. The prevalidator makes the assumption that it is faster to run than ``apply_operation``. -It can be disabled via the ``--disable-precheck`` node option. +It can be disabled via the ``--disable-mempool-precheck`` node option. The ``postfilter`` is executed on applied operations and can be used to reject some of them based on their respective (application) receipts. diff --git a/docs/user/history_modes.rst b/docs/user/history_modes.rst index 656777d754d28117a486c5f49436f3394bb3457a..40fa4f56818a25b7a649cc13aaac4f121d8f4514 100644 --- a/docs/user/history_modes.rst +++ b/docs/user/history_modes.rst @@ -41,7 +41,7 @@ Three history modes are provided: + Only requires a minimal and bounded disk storage. + Can run on low resources architectures. - + Can be bootstrapped within minutes. + + Can be bootstrapped within minutes, thanks to a rolling snapshot import. * Downsides diff --git a/src/proto_alpha/lib_protocol/contract_services.ml b/src/proto_alpha/lib_protocol/contract_services.ml index 07f0b1c454bd0b791888cd04ab9215249137d526..75a3a50a1631260c554d41a6449ce67fb5ef7a21 100644 --- a/src/proto_alpha/lib_protocol/contract_services.ml +++ b/src/proto_alpha/lib_protocol/contract_services.ml @@ -233,7 +233,7 @@ module S = struct let list = RPC_service.get_service ~description: - "All existing contracts (including non-empty default contracts)." + "All existing contracts (excluding empty implicit contracts)." ~query:RPC_query.empty ~output:(list Contract.encoding) custom_root