Part 1
요약·해설
Cherry-pick 이유 공개, 원저자 review 초대, substantial modification의 author identity 처리, Allow Edits 선택권을 다룹니다.
이유와 출처 명시
Review 초대·승인
Sign-off 선택
Part 2
접을 수 있는 영어 원문 전체
영어 원문 전체 펼치기
F3EDC237472D90DDD73EBCC0F4413347722527FBF5129876B42753B6B8A3C271
.. _modifying_contributions:
Modifying Contributions made by other developers
************************************************
Scenarios
#########
Zephyr contributors and collaborators are encouraged to assist
as reviewers in pull requests, so that patches may be approved and merged
to Zephyr's main branch as part of the original pull requests. The authors
of the pull requests are responsible for amending their original commits
following the review process.
There are occasions, however, when a contributor might need to modify patches
included in pull requests that are submitted by other Zephyr contributors.
For instance, this is the case when:
* a developer cherry-picks commits submitted by other contributors into their
own pull requests in order to:
* integrate useful content which is part of a stale pull request, or
* get content merged to the project's main branch as part of a larger
patch
* a developer pushes to a branch or pull request opened by another
contributor in order to:
* assist in updating pull requests in order to get the patches merged
to the project's main branch
* drive stale pull requests to completion so they can be merged
Accepted policies
#################
A developer who intends to cherry-pick and potentially modify patches sent by
another contributor shall:
* clarify in their pull request the reason for cherry-picking the patches,
instead of assisting in getting the patches merged in their original
pull request, and
* invite the original author of the patches to their pull request review.
A developer who intends to force-push to a branch or pull request of
another Zephyr contributor shall clarify in the pull request the reason
for pushing and for modifying the existing patches (e.g. stating that it
is done to drive the pull request review to completion, when the pull
request author is not able to do so).
.. note::
Developers should try to limit the above practice to pull requests identified
as *stale*. Read about how to identify pull requests as stale in
:ref:`development processes and tools <dev-environment-and-tools>`
If the original patches are substantially modified, the developer can either:
* (preferably) reach out to the original author and request them to
acknowledge that the modified patches may be merged while having
the original sign-off line and author identity, or
* submit the modified patches as their *own* work (i.e. with their
*own* sign-off line and author identity). In this case, the developer
shall identify in the commit message(s) the original source the
submitted work is based on (mentioning, for example, the original PR
number).
.. note::
Contributors should uncheck the box *“Allow Edits By Maintainers"*
to indicate that they do not wish their patches to be amended,
inside their original branch or pull request, by other Zephyr developers.
Part 3
한국어 전문 번역
적용 상황
Zephyr contributor와 collaborator는 pull request의 reviewer로 참여해 patch가 원래 pull request 안에서 승인되고 Zephyr main branch에 merge되도록 돕는 것이 권장됩니다. Pull request author는 review 과정에서 받은 의견에 따라 자신의 원래 commit을 수정할 책임이 있습니다.
그러나 contributor가 다른 Zephyr contributor가 제출한 pull request의 patch를 수정해야 하는 경우도 있습니다. 대표적인 상황은 다음과 같습니다.
- 다른 contributor가 제출한 commit을 자신의 pull request로 cherry-pick하는 경우. 오래되어 진행이 멈춘 pull request의 유용한 내용을 통합하거나, 더 큰 patch의 일부로 해당 내용을 project main branch에 merge하기 위해 사용할 수 있습니다.
- 다른 contributor가 연 branch 또는 pull request에 직접 push하는 경우. Pull request를 갱신해 patch가 main branch에 merge되도록 돕거나, 오래 멈춘 pull request를 완료 가능한 상태까지 이끌기 위해 사용할 수 있습니다.
허용되는 정책
다른 contributor가 보낸 patch를 cherry-pick하고 필요하면 수정하려는 developer는 자신의 pull request에서 왜 원래 pull request의 merge를 돕는 대신 patch를 cherry-pick했는지 명확히 밝혀야 합니다. 또한 원래 patch author를 새 pull request의 review에 초대해야 합니다.
다른 Zephyr contributor의 branch 또는 pull request에 force-push하려는 developer는 push와 기존 patch 수정의 이유를 pull request에 설명해야 합니다. 예를 들어 pull request author가 직접 처리할 수 없어 review를 완료 단계까지 이끌기 위한 것임을 밝힙니다.
원래 patch를 상당히 수정했다면 developer는 다음 두 방법 중 하나를 선택할 수 있습니다.
- 권장 방법은 원래 author에게 연락해, 수정된 patch가 기존 sign-off line과 author identity를 유지한 채 merge되어도 된다는 확인을 받는 것입니다.
- 수정된 patch를 자신의 작업으로 제출할 수도 있습니다. 이때 자신의 sign-off line과 author identity를 사용하고, commit message에 제출 작업의 기반이 된 원래 출처를 명시해야 합니다. 예를 들어 원래 PR 번호를 언급합니다.
Source
출처
영어 원문에는 문단, 문서 지시문, 표, 코드, 코드 심벌, 경로를 그대로 보존했습니다.