From 7bd798340be961feed88557c856af1092e286991 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Fri, 28 Feb 2025 18:53:02 +0100 Subject: [PATCH 1/8] doc: update copyright years --- docs/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/conf.py b/docs/conf.py index 09585d972020..1f850e44e22f 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -70,7 +70,7 @@ master_doc = 'index' # General information about the project. project = 'Tezos' -copyright = '2018-2024' +copyright = '2018-2025' author = 'Contributors to the Octez & Tezos protocol documentation' # The version info for the project you're documenting, acts as replacement for -- GitLab From 516920afd671eaac66b709b7f90a2ab1841d005c Mon Sep 17 00:00:00 2001 From: Valentin Chaboche Date: Mon, 3 Mar 2025 16:49:23 +0100 Subject: [PATCH 2/8] DAL/Gossip: typos --- src/lib_dal_node/gossipsub/gossipsub.mli | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/lib_dal_node/gossipsub/gossipsub.mli b/src/lib_dal_node/gossipsub/gossipsub.mli index 49cf272b6034..737f486eb276 100644 --- a/src/lib_dal_node/gossipsub/gossipsub.mli +++ b/src/lib_dal_node/gossipsub/gossipsub.mli @@ -103,34 +103,34 @@ module Transport_layer : sig (** [connect t ?timeout point] initiates a connection to the point [point]. The promise returned by this function is resolved once - the P2P handhshake successfully completes. If the [timeout] is + the P2P handshake successfully completes. If the [timeout] is set, an error is returned if the P2P handshake takes more than [timeout] to complete. *) val connect : t -> ?timeout:Ptime.Span.t -> P2p_point.Id.t -> unit tzresult Lwt.t - (** [disconnect_point t ?wait point] initiaties a disconnection to + (** [disconnect_point t ?wait point] initiates a disconnection to the point [point]. The promise returned by this function is - fullfiled when the socket is closed on our side. If [wait] is - [true], we do not close the socket before having canceled all + fulfilled when the socket is closed on our side. If [wait] is + [true], we do not close the socket before having cancelled all the current messages in the write buffer. Should not matter in practice. Due to the following issue https://gitlab.com/tezos/tezos/-/issues/5319 - it may occur that a discconnection takes several minutes. *) + it may occur that a disconnection takes several minutes. *) val disconnect_point : t -> ?wait:bool -> P2p_point.Id.t -> unit Lwt.t - (** [disconnect_peer t ?wait point] initiaties a disconnection to + (** [disconnect_peer t ?wait point] initiates a disconnection to the point [peer]. The promise returned by this function is - fullfiled when the socket is closed on our side. If [wait] is - [true], we do not close the socket before having canceled all + fulfilled when the socket is closed on our side. If [wait] is + [true], we do not close the socket before having cancelled all the current messages in the write buffer. Should not matter in practice. Due to the following issue https://gitlab.com/tezos/tezos/-/issues/5319 - it may occur that a discconnection takes several minutes. *) + it may occur that a disconnection takes several minutes. *) val disconnect_peer : t -> ?wait:bool -> Crypto_box.Public_key_hash.t -> unit Lwt.t -- GitLab From f6abaf68fe5a1cc8b7ec461073f99cc18debc936 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 10 Mar 2025 10:06:16 +0100 Subject: [PATCH 3/8] doc: fix delay for attestation rights --- docs/introduction/howtorun.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index 837830c86d00..0d181d8e97e2 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -166,7 +166,7 @@ your user account:: octez-client register key bob as delegate -Once registered, you need to wait ``consensus_rights_delay + 2 = 7`` cycles +Once registered, you need to wait the end of the current cycle plus ``consensus_rights_delay = 2`` cycles, for your rights to be considered. There is a simple rpc that can be used to check your rights for every -- GitLab From fac0d3b61038fe44816eb4af8f87dec9414512d9 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 10 Mar 2025 11:19:55 +0100 Subject: [PATCH 4/8] doc: add step of manual staking when setting up a baker --- docs/introduction/howtorun.rst | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index 0d181d8e97e2..fefc7390da97 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -165,12 +165,17 @@ To run a delegate, you first need to register as one using your user account:: octez-client register key bob as delegate + +You also need to stake some tez, as explained above, so as to have at least ``minimal_stake = 6000`` :ref:`baking power `, taking into account your own and all your delegators' staked balances, as well as their delegated balances with a lesser weight. +Most commonly, you would stake (at least) the needed amount from your own tez, without waiting for delegators:: -Once registered, you need to wait the end of the current cycle plus ``consensus_rights_delay = 2`` cycles, + octez-client stake 6000 for bob + +Once you registered and staked tez, you need to wait the end of the current cycle plus ``consensus_rights_delay = 2`` cycles, for your rights to be considered. -There is a simple rpc that can be used to check your rights for every -cycle, up to 5 cycles in the future. +There is a simple RPC that can be used to check your rights for every +cycle, up to 2 cycles in the future. :: -- GitLab From 6f153941fc1b0d73dda6f14bc1abd90269e7798b Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Tue, 11 Mar 2025 08:52:26 -0400 Subject: [PATCH 5/8] Complete sentence --- etherlink/CHANGES_NODE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/etherlink/CHANGES_NODE.md b/etherlink/CHANGES_NODE.md index fc5fdeb3f325..91cc89facf50 100644 --- a/etherlink/CHANGES_NODE.md +++ b/etherlink/CHANGES_NODE.md @@ -263,6 +263,7 @@ it is not possible to downgrade to the previous version. ### Features - Defaults to the new block storage, which significantly reduces the size of + data directories - New command `switch history to` which is now the only way to change history mode for and already populated EVM node. (!16533) - CLI command `list events`, allows listing events relative to the EVM node. (!16446) -- GitLab From 105bbb01932185e5a28e2628a94c4cdde6ead8d6 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Thu, 13 Mar 2025 09:40:00 +0100 Subject: [PATCH 6/8] doc: various fixes in Staking --- docs/alpha/staking.rst | 1 + docs/introduction/howtorun.rst | 6 +++--- etherlink/CHANGES_NODE.md | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/alpha/staking.rst b/docs/alpha/staking.rst index 4db30905d3fb..d7666749a960 100644 --- a/docs/alpha/staking.rst +++ b/docs/alpha/staking.rst @@ -22,6 +22,7 @@ Staked and delegated funds **have different weights** in the computation of delegates’ baking and voting powers: staked funds (both external stakes by stakers and the delegate’s own) count **three times** as much as delegated funds. +This ratio is defined by the protocol constant ``EDGE_OF_STAKING_OVER_DELEGATION``. Unlike delegated funds, staked funds are considered to contribute to the security deposit associated with their chosen delegate. Thus, they are diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index fefc7390da97..31b141b0f67f 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -166,15 +166,15 @@ your user account:: octez-client register key bob as delegate -You also need to stake some tez, as explained above, so as to have at least ``minimal_stake = 6000`` :ref:`baking power `, taking into account your own and all your delegators' staked balances, as well as their delegated balances with a lesser weight. +You also need to stake some tez, as explained above, so as to have at least ``MINIMAL_STAKE = 6000`` :ref:`baking power `, taking into account your own and all your delegators' staked balances, as well as their delegated balances with a lesser weight. Most commonly, you would stake (at least) the needed amount from your own tez, without waiting for delegators:: octez-client stake 6000 for bob -Once you registered and staked tez, you need to wait the end of the current cycle plus ``consensus_rights_delay = 2`` cycles, +Once you registered and staked tez, you need to wait the end of the current cycle plus ``CONSENSUS_RIGHTS_DELAY = 2`` cycles, for your rights to be considered. -There is a simple RPC that can be used to check your rights for every +There is an RPC that can be used to check your rights for every cycle, up to 2 cycles in the future. :: diff --git a/etherlink/CHANGES_NODE.md b/etherlink/CHANGES_NODE.md index 91cc89facf50..9f3dc992147d 100644 --- a/etherlink/CHANGES_NODE.md +++ b/etherlink/CHANGES_NODE.md @@ -263,7 +263,7 @@ it is not possible to downgrade to the previous version. ### Features - Defaults to the new block storage, which significantly reduces the size of - data directories + data directories. - New command `switch history to` which is now the only way to change history mode for and already populated EVM node. (!16533) - CLI command `list events`, allows listing events relative to the EVM node. (!16446) -- GitLab From 2808b2bfde697c928d02ae2352d1ebe6bf9a5dd8 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Thu, 20 Mar 2025 14:52:46 +0100 Subject: [PATCH 7/8] doc: MargeBot no longer offers priorities and uses trains --- docs/developer/contributing.rst | 45 ++------------------------------- docs/developer/guidelines.rst | 2 +- 2 files changed, 3 insertions(+), 44 deletions(-) diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst index 747c7c8e3bb6..37326c6c848d 100644 --- a/docs/developer/contributing.rst +++ b/docs/developer/contributing.rst @@ -183,22 +183,8 @@ 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 the developer (or anyone else when not possible) can assign the MR to the `Nomadic -Marge-bot `__, which will -automatically rebase the branch on top of master and finally merge it. - -Merge Queue Order ------------------ - -By default, Marge-bot will merge MRs assigned to it in the assignment order. That is, the first MR assigned is the first that is merged. There are situations when it is desirable to modify this order. To achieve this, Marge-bot respects two priority labels, whose usage is reserved to the :doc:`Octez merge team `: - -- ``marge-priority::critical``: is reserved for MRs - resolving critical production issues (e.g., fixing a blocked CI). -- ``marge-priority::high``: can be applied to MRs that needs to be - merged urgently. For instance, it can applied to MRs for urgent - releases or to reduce the merge delay between MRs that compose a - stack. - -MRs with ``marge-priority::critical`` will be treated before those with ``marge-priority::high`` who in turn will be treated before all MRs lacking either of these labels. +Marge-bot `__, which will check the MR and +automatically add it to a `merge train `__. .. _preparing_MR: @@ -727,33 +713,6 @@ pitfalls a code reviewer should avoid. When reviewing MRs involving documentation, you may check the built documentation directly within the GitLab interface, see :ref:`build_doc_ci`. -.. _merge_bot: - -The Merge-Request Bot ---------------------- - -Every 6 hours, an automated process running as the -`Tezbocop `__ 🤖 user, inspects recent MRs and posts -or edits comments on them, giving an inspection report on the contents of the -MR. - -Some warnings/comments are for you to potentially improve your MR, other -comments just help us in the assignment & review process. - -The first time Tezbocop posts a message you should receive a notification; for -the subsequent edits there won't be notifications; feel free to check Tezbocop's -comments any time. - -If you think some of the remarks/warnings do not apply to your MR feel free to -add a comment to justify it. - -In particular, the Merge-Request Bot may complain about :ref:`TODO/FIXME comments ` without an issue number ensuring that the intended evolution is tracked. - -The code for the bot is at -`oxheadalpha/merbocop `__. It is of -course work-in-progress and new warnings and comments will appear little by -little. We welcome specific issues or contributions there too. - .. _dev_tools: Developer Tools diff --git a/docs/developer/guidelines.rst b/docs/developer/guidelines.rst index 56374ff609d3..c5d31547dbce 100644 --- a/docs/developer/guidelines.rst +++ b/docs/developer/guidelines.rst @@ -74,7 +74,7 @@ In the above cases, it would be possible to create a new (sub-)issue, and refere Therefore, in such cases, it can be more convenient to refer to an MR directly. Note that the reference to an existing issue or MR on the first line is mandatory, to facilitate searches of specific evolutions. -These tags might be checked automatically by the :ref:`Merge-Request Bot `, e.g. to signal tags that refer to non-existent issues or MRs, to closed issues, or to already merged MRs. +These tags might be checked automatically, e.g. to signal tags that refer to non-existent issues or MRs, to closed issues, or to already merged MRs. The reference to an issue may be one of: - a URL such as ``https://gitlab.com/tezos/tezos/-/issues/1377`` -- GitLab From 44356859ac8164c8294fc1969ab543f47f403230 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Fri, 21 Mar 2025 14:06:00 +0100 Subject: [PATCH 8/8] doc: fix some broken/redirected links --- docs/README.rst | 2 +- docs/conf.py | 2 ++ docs/developer/contributing.rst | 8 ++++---- docs/developer/testing.rst | 4 ++-- docs/user/node-configuration.rst | 4 ++-- 5 files changed, 11 insertions(+), 9 deletions(-) diff --git a/docs/README.rst b/docs/README.rst index da245f2e06e3..ca5aad27201c 100644 --- a/docs/README.rst +++ b/docs/README.rst @@ -106,7 +106,7 @@ Some ad-hoc reference kinds are supported. (``package.version``) - ``:gl:`[special gitlab reference]``` or ``:gl:`text <[special gitlab reference]>``` expands and links `GitLab special references - `_, + `_, like for merge requests :gl:`tezos/tezos!123` (``:gl:`tezos/tezos!123```), issues :gl:`tezos/tezos#999` (``:gl:`tezos/tezos#999```) diff --git a/docs/conf.py b/docs/conf.py index 1f850e44e22f..78d6adf610c8 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -262,6 +262,8 @@ linkcheck_ignore = [ r'^https://crates\.io/crates/tezos-smart-rollup', r'^https://rpc\.ghostnet\.teztnets\.com/chains/main/blocks/', r'^https://gitlab\.com/tezos/tezos/-/merge_requests/2771', + r'^https://gitlab\.com/tezos/tezos/-/merge_requests/3163', + r'^https://gitlab\.com/tezos/tezos/-/merge_requests/3225', ] linkcheck_allowed_redirects = dict( [ diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst index 37326c6c848d..67dcfc82eae3 100644 --- a/docs/developer/contributing.rst +++ b/docs/developer/contributing.rst @@ -96,7 +96,7 @@ merge request is ready, it is reviewed and approved, then merged with a merge co Therefore, you can bring useful contributions both by creating your own MRs and by reviewing MRs submitted by others. -We maintain a `semi-linear history `_, +We maintain a `semi-linear history `_, which means that merge requests are only merged if they are direct suffixes of the master branch. This means that merge requests are rebased on top of ``master`` before they are merged. @@ -155,7 +155,7 @@ approach will make it easier for the reviewer to keep interacting till each discussion is resolved. When the reviewer is satisfied, they will mark the discussion resolved. -The `Draft: `_ +The `Draft: `_ status can be set at any time during the authoring/review process to signal that the MR is not yet ready for merge (for instance, the ``git`` history might not be clean). But, the @@ -456,7 +456,7 @@ To find reviewers, either: - Ask help to the :ref:`merge coordinator `, either by asking them on Slack or mentioning them in a comment (see next paragraph). -Depending on your `GitLab role `_ +Depending on your `GitLab role `_ you may or may not be able to use the *Reviewers* field for specifying the reviewers. If you don't have the right, mention the reviewers using their GitLab handle (username prefixed with ``@``) in a comment. @@ -469,7 +469,7 @@ Merge Request "Draft" Mode A merge request that is not yet ready to be merged should be marked as `draft -`_ +`_ by prefixing its title with ``Draft:``. Typical reasons for this is that the author still has some minor tasks to accomplish, such as cleaning up the merge request's ``git`` history (e.g. squashing ``fixup!`` commits), even diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index 70fc5eea0abf..e4f17b162672 100644 --- a/docs/developer/testing.rst +++ b/docs/developer/testing.rst @@ -475,7 +475,7 @@ The results of the test suite on terminated pipelines is presented on the details of the merge request page corresponding to the pipeline's branch (if any). For more information, see the `GitLab documentation on Unit test reports -`__. +`__. By default, the ``test`` of the CI runs the tests as a set of independent jobs that cluster the tests with a varying grain. This strikes a balance between exploiting GitLab @@ -531,7 +531,7 @@ The summary report gives the merge request an overall test coverage percentage Additionally, using ``bisect-ppx-report cobertura``, we produce and upload a Cobertura artifact activating the `test coverage visualization -`_ +`_ in GitLab: .. image:: images/testing-coverage-markers.png diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst index 6c898d8526d5..dcf7ed93a305 100644 --- a/docs/user/node-configuration.rst +++ b/docs/user/node-configuration.rst @@ -285,14 +285,14 @@ HTTP Caching Headers It is possible to enable http caching headers in the RPC responses with the ``--enable-http-cache-headers`` option. This feature is disabled by default. -When enabled, the RPC server will support `max-age `_ +When enabled, the RPC server will support `max-age `_ header. The header ``Cache-control: public, max-age: `` will be included in the response headers of head related queries (``/chains/main/blocks/head*``) for responses that are cacheable. This also works on paths that are relative to ``head`` such as ``head-n`` and ``head~n``. The response is cacheable throughout the ```` of the head block's consensus round where ```` is the remaining time until the :ref:`estimated end time` of the consensus round. If a response should not be cached, the RPC server will not include any cache control headers. -The RPC server will also support the conditional request header `If-None-Match `_ +The RPC server will also support the conditional request header `If-None-Match `_ and include the ``ETag`` field in every head related query. The value of the ``ETag`` will be set to the block hash that the query is related to. If the client sends a request with ``If-None-Match: `` header and the block hash is included in the list of etag values, the RPC server will respond with a ``304 Not Modified`` status code with an empty body. -- GitLab