From 26294ced096cb8a5491ffe826b675df2af6aab1f Mon Sep 17 00:00:00 2001 From: Carles Cufi Date: Tue, 14 Jun 2022 15:30:17 +0200 Subject: [PATCH] doc: Rename API meeting to Architecture meeting As per the decision to rename this meeting and make it into a working group, document this in the official docs. Signed-off-by: Carles Cufi --- doc/develop/api/api_lifecycle.rst | 13 +++++++------ doc/project/dev_env_and_tools.rst | 2 +- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/doc/develop/api/api_lifecycle.rst b/doc/develop/api/api_lifecycle.rst index 38434ffdd57..404eb01b60a 100644 --- a/doc/develop/api/api_lifecycle.rst +++ b/doc/develop/api/api_lifecycle.rst @@ -91,8 +91,8 @@ In order to declare an API ``stable``, the following steps need to be followed: #. An email must be sent to the ``devel`` mailing list announcing the API upgrade request #. The Pull Request must be submitted for discussion in the next - `Zephyr API meeting`_ where, barring any objections, the Pull Request will be - merged + `Zephyr Architecture meeting`_ where, barring any objections, the Pull Request + will be merged .. _stable_api_changes: @@ -134,13 +134,14 @@ such a change is considered necessary in order to accept it in the project: Instead of a written description of the changes, the RFC issue may link to a Pull Request containing those changes in code form. #. The RFC issue must be labeled with the GitHub ``Stable API Change`` label -#. The RFC issue must be submitted for discussion in the next `Zephyr API meeting`_ +#. The RFC issue must be submitted for discussion in the next `Zephyr + Architecture meeting`_ #. An email must be sent to the ``devel`` mailing list with a subject identical to the RFC issue title and that links to the RFC issue The RFC will then receive feedback through issue comments and will also be -discussed in the Zephyr API meeting, where the stakeholders and the community at -large will have a chance to discuss it in detail. +discussed in the Zephyr Architecture meeting, where the stakeholders and the +community at large will have a chance to discuss it in detail. Finally, and if not done as part of the first step, a Pull Request must be opened on GitHub. It is left to the person proposing the change to decide @@ -242,4 +243,4 @@ migration and update the roadmap with the aim to remove the API in the next release. .. _`Zephyr TSC meeting`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#technical-steering-committee-tsc -.. _`Zephyr API meeting`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-meeting +.. _`Zephyr Architecture meeting`: https://github.com/zephyrproject-rtos/zephyr/wiki/Architecture-Working-Group diff --git a/doc/project/dev_env_and_tools.rst b/doc/project/dev_env_and_tools.rst index 7c3abaaa1b4..c6f76814ffc 100644 --- a/doc/project/dev_env_and_tools.rst +++ b/doc/project/dev_env_and_tools.rst @@ -111,7 +111,7 @@ TSC and Working Groups Changes that introduce new features or functionality or change the way the overall system works need to be reviewed by the TSC or the responsible Working Group. For example for :ref:`stable API changes `, the -proposal needs to be presented in the API meeting so that the relevant +proposal needs to be presented in the Architecture meeting so that the relevant stakeholders are made aware of the change. A Pull-Request should have an Assignee