요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _modifyingpatches:
Modifying Patches
=================
If you are a subsystem or branch maintainer, sometimes you need to slightly
modify patches you receive in order to merge them, because the code is not
exactly the same in your tree and the submitters'. If you stick strictly to
rule (c) of the developers certificate of origin, you should ask the submitter
to rediff, but this is a totally counter-productive waste of time and energy.
Rule (b) allows you to adjust the code, but then it is very impolite to change
one submitters code and make him endorse your bugs. To solve this problem, it
is recommended that you add a line between the last Signed-off-by header and
yours, indicating the nature of your changes. While there is nothing mandatory
about this, it seems like prepending the description with your mail and/or
name, all enclosed in square brackets, is noticeable enough to make it obvious
that you are responsible for last-minute changes. Example::
Signed-off-by: Random J Developer <[email protected]>
[[email protected]: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <[email protected]>
This practice is particularly helpful if you maintain a stable branch and
want at the same time to credit the author, track changes, merge the fix,
and protect the submitter from complaints. Note that under no circumstances
can you change the author's identity (the From header), as it is the one
which appears in the changelog.
Special note to back-porters: It seems to be a common and useful practice
to insert an indication of the origin of a patch at the top of the commit
message (just after the subject line) to facilitate tracking. For instance,
here's what we see in a 3.x-stable release::
Date: Tue Oct 7 07:26:38 2014 -0400
libata: Un-break ATA blacklist
commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.
And here's what might appear in an older kernel once a patch is backported::
Date: Tue May 13 22:12:27 2008 +0200
wireless, airo: waitbusy() won't delay
[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
Whatever the format, this information provides a valuable help to people
tracking your trees, and to people trying to troubleshoot bugs in your
tree.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Maintainer 수정과 책임 표시
1-28Subsystem 또는 branch maintainer는 자신의 tree와 제출자의 tree가 조금 달라 patch를 merge하려면 받은 patch를 약간 수정해야 할 때가 있습니다.
Developer Certificate of Origin의 rule (c)를 엄격히 적용하면 제출자에게 다시 diff를 만들라고 해야 하지만, 작은 조정에 시간과 에너지를 낭비할 수 있습니다. Rule (b)는 maintainer가 code를 조정할 수 있게 합니다.
다만 제출자의 code를 바꾼 뒤 maintainer가 만든 bug까지 제출자가 보증하게 만드는 것은 부적절합니다. 이를 피하려면 마지막 제출자 `Signed-off-by`와 maintainer의 `Signed-off-by` 사이에 수정 내용과 책임자를 나타내는 줄을 추가하는 것이 권장됩니다.
필수 형식은 아니지만 `[email 또는 이름: 변경 설명]`처럼 대괄호 안에 책임자와 내용을 쓰면 마지막 순간의 수정 책임이 maintainer에게 있음을 분명히 알 수 있습니다.
이 관행은 stable branch에서 원저자에게 공로를 주고, 변경을 추적하고, fix를 merge하면서 제출자를 잘못된 비난에서 보호하는 데 특히 유용합니다.
어떤 경우에도 author identity인 `From` header를 바꾸면 안 됩니다. 이 값이 changelog에 나타나는 작성자이기 때문입니다.
원저자 identity와 maintainer가 추가한 수정 책임을 함께 보존합니다.
제출자에게 불필요한 rediff를 요구하지 않으면서 책임을 분리합니다.
.. _modifyingpatches:
Modifying Patches
=================
If you are a subsystem or branch maintainer, sometimes you need to slightly
modify patches you receive in order to merge them, because the code is not
exactly the same in your tree and the submitters'. If you stick strictly to
rule (c) of the developers certificate of origin, you should ask the submitter
to rediff, but this is a totally counter-productive waste of time and energy.
Rule (b) allows you to adjust the code, but then it is very impolite to change
one submitters code and make him endorse your bugs. To solve this problem, it
is recommended that you add a line between the last Signed-off-by header and
yours, indicating the nature of your changes. While there is nothing mandatory
about this, it seems like prepending the description with your mail and/or
name, all enclosed in square brackets, is noticeable enough to make it obvious
that you are responsible for last-minute changes. Example::
Signed-off-by: Random J Developer <[email protected]>
[[email protected]: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <[email protected]>
This practice is particularly helpful if you maintain a stable branch and
want at the same time to credit the author, track changes, merge the fix,
and protect the submitter from complaints. Note that under no circumstances
can you change the author's identity (the From header), as it is the one
which appears in the changelog.
Backport 원본 추적
29-50Backporter는 추적을 쉽게 하도록 commit message 상단, subject 바로 다음에 patch 원본을 표시하는 것이 일반적이고 유용합니다.
3.x stable 예시는 `commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.`처럼 upstream commit id를 기록합니다.
더 오래된 kernel에 backport한 예시는 `[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]`처럼 원본 version과 commit을 대괄호로 표시합니다.
정확한 문구보다 원본을 명확히 추적할 수 있다는 점이 중요합니다. 이 정보는 tree의 변경을 따라가는 사람과 해당 tree의 bug를 진단하는 사람 모두에게 큰 도움이 됩니다.
Commit message에서 upstream 기원을 바로 찾을 수 있게 합니다.
Special note to back-porters: It seems to be a common and useful practice
to insert an indication of the origin of a patch at the top of the commit
message (just after the subject line) to facilitate tracking. For instance,
here's what we see in a 3.x-stable release::
Date: Tue Oct 7 07:26:38 2014 -0400
libata: Un-break ATA blacklist
commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.
And here's what might appear in an older kernel once a patch is backported::
Date: Tue May 13 22:12:27 2008 +0200
wireless, airo: waitbusy() won't delay
[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
Whatever the format, this information provides a valuable help to people
tracking your trees, and to people trying to troubleshoot bugs in your
tree.
요약·해설
modifying-patches.rst:1-50작은 maintainer 수정은 제출자의 sign-off와 maintainer sign-off 사이에 `[maintainer: 변경 설명]`을 넣어 책임을 분리합니다.
원저자의 `From` identity는 바꾸지 않으며, backport commit message에는 대응 upstream commit을 명시해 추적 가능성을 유지합니다.