contribute/proposals_and_rfcs.html · contribute/proposals_and_rfcs.rst 공식 원문 ↗

Zephyr 3.7.0 · Contribute · RFC

Proposals and RFCs

큰 변경을 구현하기 전에 이해관계자의 의견을 모으고 설계를 개선하는 공식 RFC 경로를 설명합니다.

Official pathcontribute/proposals_and_rfcs.html
Source filecontribute/proposals_and_rfcs.rst
Source versionZephyr 3.7.0
TranslationFull · reviewed

본문 기준: Zephyr 3.7.0 LTS3 · 이후 유지보수 패치는 별도입니다.

Part 1

요약·해설

API 추가·stable API 수정·release feature 제거·새 convention에는 RFC를 고려하고, refactoring이나 기존 subsystem의 board·SoC·driver 추가에는 일반적으로 필요하지 않다고 구분합니다.

대상

API · Feature · Convention

형식

Issue · RFC Label

합의

Review · Meeting

Part 2

접을 수 있는 영어 원문 전체

영어 원문 전체 펼치기
원문 SHA-256 65CC37A8FBD8126234B6CBE691AF30A3B2EADC33C8980FFD550E87782F00139E
.. _rfcs:

Proposals and RFCs
##################

Many changes, including bug fixes and documentation improvements can be
implemented and reviewed via the normal GitHub pull request workflow.

Many changes however are "substantial" and need to go through a
design process and produce a consensus among the project stakeholders.

The "RFC" (request for comments) process is intended to provide a consistent and
controlled path for new features to enter the project.

Contributors and project stakeholders should consider using this process if
they intend to make "substantial" changes to Zephyr or its documentation. Some
examples that would benefit from an RFC are:

- A new feature that creates new API surface area, and would require a feature
  flag if introduced.
- The modification of an existing stable API.
- The removal of features that already shipped as part of Zephyr.
- The introduction of new idiomatic usage or conventions, even if they do not
  include code changes to Zephyr itself.

The RFC process is a great opportunity to get more eyeballs on proposals coming
from contributors before it becomes a part of Zephyr. Quite often, even
proposals that seem "obvious" can be significantly improved once a wider group
of interested people have a chance to weigh in.

The RFC process can also be helpful to encourage discussions about a proposed
feature as it is being designed, and incorporate important constraints into the
design while it's easier to change, before the design has been fully
implemented.

Some changes do not require an RFC:

- Rephrasing, reorganizing or refactoring
- Addition or removal of warnings
- Addition of new boards, SoCs or drivers to existing subsystems
- ...

The process in itself consists in creating a GitHub issue with the :ref:`RFC
label <gh_labels>` that documents the proposal thoroughly. There is an `RFC
template`_ included in the main Zephyr GitHub repository that serves as a
guideline to write a new RFC.

As with Pull Requests, RFCs might require discussion in the context of one of
the `Zephyr meetings`_ in order to move it forward in cases where there is
either disagreement or not enough voiced opinions in order to proceed. Make sure
to either label it appropriately or include it in the corresponding GitHub
project in order for it to be examined during the next meeting.

.. _`RFC template`: https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/003_rfc-proposal.md
.. _`Zephyr meetings`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings

Part 3

한국어 전문 번역

Proposal과 RFC

Bug fix와 documentation 개선을 포함한 많은 변경은 일반 GitHub Pull Request workflow로 구현하고 review할 수 있습니다.

그러나 많은 변경은 project stakeholder가 합의할 수 있도록 design process를 거쳐야 하는 ‘substantial’ change입니다.

RFC(request for comments) 절차는 새 feature가 일관되고 통제된 경로로 project에 들어오게 하기 위한 것입니다.

Contributor와 project stakeholder는 Zephyr 또는 그 documentation에 substantial change를 만들려 할 때 이 절차를 사용하는 것을 고려해야 합니다. RFC가 유용한 예:

  • 새 API surface area를 만들며 도입할 때 feature flag가 필요한 새 feature
  • 기존 stable API의 수정
  • 이미 Zephyr 일부로 release된 feature의 제거
  • Zephyr code 자체를 바꾸지 않더라도 새로운 idiomatic usage나 convention의 도입

RFC 절차는 contributor의 proposal이 Zephyr 일부가 되기 전에 더 많은 사람이 살펴보게 하는 좋은 기회입니다. 처음에는 ‘명백해’ 보이는 proposal도 관심 있는 더 넓은 집단이 의견을 내면 크게 개선되는 경우가 많습니다.

제안 feature를 design하는 동안 토론을 촉진하고, 구현이 끝난 뒤보다 변경하기 쉬운 시점에 중요한 constraint를 design에 포함하는 데에도 RFC가 도움이 됩니다.

다음 변경은 RFC가 필요하지 않습니다.

  • 문구 수정, 재구성 또는 refactoring
  • Warning 추가 또는 제거
  • 기존 subsystem에 새 board, SoC 또는 driver 추가
  • 그 밖의 비슷한 소규모 변경

절차 자체는 proposal을 충분히 자세히 기록한 GitHub issue를 만들고 RFC label을 붙이는 것입니다. Main Zephyr GitHub repository의 RFC template이 새 RFC 작성 지침을 제공합니다.

Pull Request와 마찬가지로 의견 충돌이 있거나 진행하기에 충분한 의견이 나오지 않으면 RFC를 진전시키기 위해 Zephyr meeting에서 논의해야 할 수 있습니다. 다음 meeting에서 검토할 수 있도록 적절한 label을 붙이거나 해당 GitHub project에 포함하십시오.

Source

출처

영어 원문에는 문단, 문서 지시문, 표, 코드, 코드 심벌, 경로를 그대로 보존했습니다.