michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: Rename API meeting to Architecture meeting

Browse source 
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 <carles.cufi@nordicsemi.no>
This commit is contained in:
Carles Cufi 2022-06-14 15:30:17 +02:00 • committed by Carles Cufí
commit 26294ced09
2 changed files with 8 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

13
doc/develop/api/api_lifecycle.rst
View file

@ -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 #. An email must be sent to the ``devel`` mailing list announcing the API
upgrade request upgrade request
#. The Pull Request must be submitted for discussion in the next #. The Pull Request must be submitted for discussion in the next
`Zephyr API meeting`_ where, barring any objections, the Pull Request will be `Zephyr Architecture meeting`_ where, barring any objections, the Pull Request
merged will be merged
.. _stable_api_changes: .. _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 Instead of a written description of the changes, the RFC issue may link to a
Pull Request containing those changes in code form. 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 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 #. 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 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 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 discussed in the Zephyr Architecture meeting, where the stakeholders and the
large will have a chance to discuss it in detail. 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 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 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. release.
.. _`Zephyr TSC meeting`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#technical-steering-committee-tsc .. _`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

2
doc/project/dev_env_and_tools.rst
View file

@ -111,7 +111,7 @@ TSC and Working Groups
Changes that introduce new features or functionality or change the way the 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 overall system works need to be reviewed by the TSC or the responsible Working
Group. For example for :ref:`stable API changes <stable_api_changes>`, the Group. For example for :ref:`stable API changes <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. stakeholders are made aware of the change.
A Pull-Request should have an Assignee A Pull-Request should have an Assignee