diff --git a/docs/README.rst b/docs/README.rst index da245f2e06e3d8ab47c35f92d4394f0107c50326..ca5aad27201cb70b8f37eac079eb72fc007eb83d 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/alpha/staking.rst b/docs/alpha/staking.rst index 4db30905d3fbab6724e60f0705becf5a9e1fe2d1..d7666749a960a8eb42a9adcc85603999fadb56c0 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/conf.py b/docs/conf.py index 09585d97202064f6ce31d03265a18ee040ac32df..78d6adf610c8e3ef27a2c2d494d0018d27165cc7 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 @@ -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 747c7c8e3bb698a0b50fbf1dd8e7d4805aa8dbab..67dcfc82eae30ce4fdd4d6f639ecae8a1e67bba7 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 @@ -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: @@ -470,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. @@ -483,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 @@ -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 56374ff609d35e11ebaf81b602351b8f4bb5c6c0..c5d31547dbcef38b115cfe17c5b730923619f1c6 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`` diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index 70fc5eea0abfc8e5314ee0fca1adc732323ac1fd..e4f17b162672a5497bc5c181a7ba9cb97580c7c6 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/introduction/howtorun.rst b/docs/introduction/howtorun.rst index 837830c86d00fe0fd88fdea446c30b88124d7f05..31b141b0f67f7a1970f0b494115b448052f9c4fe 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 ``consensus_rights_delay + 2 = 7`` 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 an RPC that can be used to check your rights for every +cycle, up to 2 cycles in the future. :: diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst index 6c898d8526d58db7a616b7c8ca4d8526a16b6e92..dcf7ed93a30513b46c40f3173f680b1f6c5760bc 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. diff --git a/etherlink/CHANGES_NODE.md b/etherlink/CHANGES_NODE.md index fc5fdeb3f325a0886800e8430c9ccf4e15eb16e5..9f3dc992147d749740cf238b06f043494771f4e6 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) diff --git a/src/lib_dal_node/gossipsub/gossipsub.mli b/src/lib_dal_node/gossipsub/gossipsub.mli index 49cf272b60341ea30efe4b71cfe7942b4c919905..737f486eb2769b9bfac4eccb63a5b3716ef5f10a 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