요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Reviewer와 협업하기
6.Followthrough.rst:22-109Reviewer는 지금 동작하는지만 보지 않고 이 code가 들어간 kernel을 5년, 10년 뒤에도 유지할 수 있는지 묻는다. Style 수정부터 큰 rewrite까지 많은 요구가 장기 유지 가능성에서 나온다.
Code review는 어렵고 눈에 띄는 보상은 적어 reviewer가 같은 실수를 반복해서 보면 날카롭게 말할 수 있다. 표현이 불쾌해 보여도 같은 방식으로 대응하지 말고 사람과 code를 분리해 기술적 관찰을 이해해야 한다.
Reviewer가 고용주의 agenda를 위해 경쟁 회사를 방해한다고 가정하지 않는다. Kernel developer는 고용주가 바뀔 수 있음을 알면서도 장기간 유지할 최선의 kernel을 목표로 한다.
사소해 보이는 style 변경이나 shared kernel code로 기능을 끌어올리라는 요구에도 이유가 있다. Driver 안의 clever workaround가 다음 사용자를 위한 일반 kernel feature가 되어야 할 수 있다.
- Comment의 기술적 의미를 충분히 이해한다.
- 가능하면 요청된 문제를 고친다.
- Reviewer에게 감사하고 질문과 요청에 어떻게 대응할지 reply한다.
- 동의하지 않으면 code가 실제로 어떻게 동작하는지 또는 제안에 반대하는 기술적 이유를 설명한다.
- 여러 사람이 reviewer 의견에 동의하면 자신의 solution이나 문제 정의가 잘못됐는지 다시 검토한다.
Andrew Morton은 code 변경으로 이어지지 않은 review comment마다 future reviewer가 같은 질문을 하지 않도록 code comment를 추가하는 방식을 제안했다.
Review comment를 무시하고 같은 code를 다시 게시하면 문제는 사라지지 않고 patch가 더 이상 진행되지 않는다.
새 version을 게시할 때 이전에 나온 issue와 처리 방법을 changelog에 적는다. Reviewer에게 archive를 다시 뒤지게 하지 않아야 다음 review를 빠르게 시작할 수 있다.
모든 대화를 해도 기술적 교착이 풀리지 않고 결정이 부당하다고 확신하면 더 높은 maintainer에게 판단을 요청할 수 있다. 원문 작성 시점에는 Andrew Morton이 그런 역할을 자주 했지만, 다른 방법을 모두 시도한 뒤 신중히 요청해야 하며 그 역시 자신의 편을 들지 않을 수 있다.
Subsystem tree와 linux-next
6.Followthrough.rst:111-151Patch가 유용하고 주요 review issue가 해결되면 보통 subsystem maintainer tree에 들어간다. Subsystem마다 절차가 다르고 다음 merge window용 tree와 장기 작업 tree를 따로 둘 수 있다.
명확한 subsystem tree가 없는 memory-management 같은 patch나 여러 subsystem에 걸친 patch는 -mm를 거칠 수 있다.
Subsystem tree에 들어가면 그 tree를 사용하는 개발자와 linux-next 전체 사용자에게 기본적으로 노출되어 새로운 reviewer comment가 나올 수 있다. 이전과 같은 방식으로 대응해야 한다.
다른 tree의 작업과 conflict가 발견되면 일부 작업을 미루거나 관련 개발자와 함께 conflict를 풀고 patch를 tree 사이로 이동할 수 있다. linux-next 덕분에 이런 문제를 merge window의 급박한 시점이 아니라 미리 해결할 수 있다.
Mainline merge 뒤의 책임
6.Followthrough.rst:153-190Mainline merge는 축하할 일이지만 끝이 아니다. 더 많은 개발자가 code를 보고 새 질문과 suggestion을 보낼 수 있으며 이미 merge됐다는 이유로 무시하면 안 된다.
더 큰 tester 집단이 code를 build하고 실행하면서 bug report가 나온다. 출시 전 hardware driver라도 예상보다 많은 사람이 build할 수 있다.
Regression은 즉시 고쳐야 한다. Author가 고칠 의지나 능력이 없고 다른 사람도 고치지 않으면 stabilization 기간에 patch가 제거될 가능성이 매우 높다. 이는 이전 노력을 무효로 만들고 미래 patch에 대한 신뢰도 낮춘다.
Regression 뒤에는 일반 bug를 고친다. Stabilization 기간은 code가 첫 mainline release에 안정적으로 들어가게 할 가장 좋은 기회이며, 기존 문제를 처리한 뒤 새 feature 작업을 시작해야 한다.
다음 stable release와 distribution 채택 시점에도 새 report가 나올 수 있다. Merge 뒤 code에 관심을 잃는 개발자는 community가 기억하며 다음 patch도 유지하지 않을 것이라는 가정 아래 평가받는다.
다른 사람이 내 code를 바꿀 때
6.Followthrough.rst:192-220다른 사람이 내 code에 patch를 보내고 동의한다면 실제 author의 From을 보존하고 자신의 signoff를 더해 maintainer에게 전달하거나 Acked-by로 원 게시자가 올리게 할 수 있다.
동의하지 않으면 이유와 받아들일 수 있게 만드는 변경 조건을 정중히 설명한다. Code author와 maintainer의 반대는 무게가 있지만 절대 veto는 아니다. 좋은 작업을 근거 없이 막는다고 보이면 patch는 우회해 mainline으로 갈 수 있다.
다른 개발자가 같은 문제의 더 나은 solution을 게시해 자신의 patch가 선택되지 않을 수도 있다. 먼저 만들었다는 사실은 기술적 근거가 아니다. 문제 자체가 해결된 것을 긍정적으로 받아들이는 반응이 중요하며, community는 어느 patch가 merge됐는지보다 그 상황에서 보인 태도를 오래 기억한다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _development_followthrough:
Followthrough
=============
At this point, you have followed the guidelines given so far and, with the
addition of your own engineering skills, have posted a perfect series of
patches. One of the biggest mistakes that even experienced kernel
developers can make is to conclude that their work is now done. In truth,
posting patches indicates a transition into the next stage of the process,
with, possibly, quite a bit of work yet to be done.
It is a rare patch which is so good at its first posting that there is no
room for improvement. The kernel development process recognizes this fact,
and, as a result, is heavily oriented toward the improvement of posted
code. You, as the author of that code, will be expected to work with the
kernel community to ensure that your code is up to the kernel's quality
standards. A failure to participate in this process is quite likely to
prevent the inclusion of your patches into the mainline.
Working with reviewers
----------------------
A patch of any significance will result in a number of comments from other
developers as they review the code. Working with reviewers can be, for
many developers, the most intimidating part of the kernel development
process. Life can be made much easier, though, if you keep a few things in
mind:
- If you have explained your patch well, reviewers will understand its
value and why you went to the trouble of writing it. But that value
will not keep them from asking a fundamental question: what will it be
like to maintain a kernel with this code in it five or ten years later?
Many of the changes you may be asked to make - from coding style tweaks
to substantial rewrites - come from the understanding that Linux will
still be around and under development a decade from now.
- Code review is hard work, and it is a relatively thankless occupation;
people remember who wrote kernel code, but there is little lasting fame
for those who reviewed it. So reviewers can get grumpy, especially when
they see the same mistakes being made over and over again. If you get a
review which seems angry, insulting, or outright offensive, resist the
impulse to respond in kind. Code review is about the code, not about
the people, and code reviewers are not attacking you personally.
- Similarly, code reviewers are not trying to promote their employers'
agendas at the expense of your own. Kernel developers often expect to
be working on the kernel years from now, but they understand that their
employer could change. They truly are, almost without exception,
working toward the creation of the best kernel they can; they are not
trying to create discomfort for their employers' competitors.
- Be prepared for seemingly silly requests for coding style changes
and requests to factor out some of your code to shared parts of
the kernel. One job the maintainers do is to keep things looking
the same. Sometimes this means that the clever hack in your driver
to get around a problem actually needs to become a generalized
kernel feature ready for next time.
What all of this comes down to is that, when reviewers send you comments,
you need to pay attention to the technical observations that they are
making. Do not let their form of expression or your own pride keep that
from happening. When you get review comments on a patch, take the time to
understand what the reviewer is trying to say. If possible, fix the things
that the reviewer is asking you to fix. And respond back to the reviewer:
thank them, and describe how you will answer their questions.
Note that you do not have to agree with every change suggested by
reviewers. If you believe that the reviewer has misunderstood your code,
explain what is really going on. If you have a technical objection to a
suggested change, describe it and justify your solution to the problem. If
your explanations make sense, the reviewer will accept them. Should your
explanation not prove persuasive, though, especially if others start to
agree with the reviewer, take some time to think things over again. It can
be easy to become blinded by your own solution to a problem to the point
that you don't realize that something is fundamentally wrong or, perhaps,
you're not even solving the right problem.
Andrew Morton has suggested that every review comment which does not result
in a code change should result in an additional code comment instead; that
can help future reviewers avoid the questions which came up the first time
around.
One fatal mistake is to ignore review comments in the hope that they will
go away. They will not go away. If you repost code without having
responded to the comments you got the time before, you're likely to find
that your patches go nowhere.
Speaking of reposting code: please bear in mind that reviewers are not
going to remember all the details of the code you posted the last time
around. So it is always a good idea to remind reviewers of previously
raised issues and how you dealt with them; the patch changelog is a good
place for this kind of information. Reviewers should not have to search
through list archives to familiarize themselves with what was said last
time; if you help them get a running start, they will be in a better mood
when they revisit your code.
What if you've tried to do everything right and things still aren't going
anywhere? Most technical disagreements can be resolved through discussion,
but there are times when somebody simply has to make a decision. If you
honestly believe that this decision is going against you wrongly, you can
always try appealing to a higher power. As of this writing, that higher
power tends to be Andrew Morton. Andrew has a great deal of respect in the
kernel development community; he can often unjam a situation which seems to
be hopelessly blocked. Appealing to Andrew should not be done lightly,
though, and not before all other alternatives have been explored. And bear
in mind, of course, that he may not agree with you either.
What happens next
-----------------
If a patch is considered to be a good thing to add to the kernel, and once
most of the review issues have been resolved, the next step is usually
entry into a subsystem maintainer's tree. How that works varies from one
subsystem to the next; each maintainer has his or her own way of doing
things. In particular, there may be more than one tree - one, perhaps,
dedicated to patches planned for the next merge window, and another for
longer-term work.
For patches applying to areas for which there is no obvious subsystem tree
(memory management patches, for example), the default tree often ends up
being -mm. Patches which affect multiple subsystems can also end up going
through the -mm tree.
Inclusion into a subsystem tree can bring a higher level of visibility to a
patch. Now other developers working with that tree will get the patch by
default. Subsystem trees typically feed linux-next as well, making their
contents visible to the development community as a whole. At this point,
there's a good chance that you will get more comments from a new set of
reviewers; these comments need to be answered as in the previous round.
What may also happen at this point, depending on the nature of your patch,
is that conflicts with work being done by others turn up. In the worst
case, heavy patch conflicts can result in some work being put on the back
burner so that the remaining patches can be worked into shape and merged.
Other times, conflict resolution will involve working with the other
developers and, possibly, moving some patches between trees to ensure that
everything applies cleanly. This work can be a pain, but count your
blessings: before the advent of the linux-next tree, these conflicts often
only turned up during the merge window and had to be addressed in a hurry.
Now they can be resolved at leisure, before the merge window opens.
Some day, if all goes well, you'll log on and see that your patch has been
merged into the mainline kernel. Congratulations! Once the celebration is
complete (and you have added yourself to the MAINTAINERS file), though, it
is worth remembering an important little fact: the job still is not done.
Merging into the mainline brings its own challenges.
To begin with, the visibility of your patch has increased yet again. There
may be a new round of comments from developers who had not been aware of
the patch before. It may be tempting to ignore them, since there is no
longer any question of your code being merged. Resist that temptation,
though; you still need to be responsive to developers who have questions or
suggestions.
More importantly, though: inclusion into the mainline puts your code into
the hands of a much larger group of testers. Even if you have contributed
a driver for hardware which is not yet available, you will be surprised by
how many people will build your code into their kernels. And, of course,
where there are testers, there will be bug reports.
The worst sort of bug reports are regressions. If your patch causes a
regression, you'll find an uncomfortable number of eyes upon you;
regressions need to be fixed as soon as possible. If you are unwilling or
unable to fix the regression (and nobody else does it for you), your patch
will almost certainly be removed during the stabilization period. Beyond
negating all of the work you have done to get your patch into the mainline,
having a patch pulled as the result of a failure to fix a regression could
well make it harder for you to get work merged in the future.
After any regressions have been dealt with, there may be other, ordinary
bugs to deal with. The stabilization period is your best opportunity to
fix these bugs and ensure that your code's debut in a mainline kernel
release is as solid as possible. So, please, answer bug reports, and fix
the problems if at all possible. That's what the stabilization period is
for; you can start creating cool new patches once any problems with the old
ones have been taken care of.
And don't forget that there are other milestones which may also create bug
reports: the next mainline stable release, when prominent distributors pick
up a version of the kernel containing your patch, etc. Continuing to
respond to these reports is a matter of basic pride in your work. If that
is insufficient motivation, though, it's also worth considering that the
development community remembers developers who lose interest in their code
after it's merged. The next time you post a patch, they will be evaluating
it with the assumption that you will not be around to maintain it
afterward.
Other things that can happen
-----------------------------
One day, you may open your mail client and see that somebody has mailed you
a patch to your code. That is one of the advantages of having your code
out there in the open, after all. If you agree with the patch, you can
either forward it on to the subsystem maintainer (be sure to include a
proper From: line so that the attribution is correct, and add a signoff of
your own), or send an Acked-by: response back and let the original poster
send it upward.
If you disagree with the patch, send a polite response explaining why. If
possible, tell the author what changes need to be made to make the patch
acceptable to you. There is a certain resistance to merging patches which
are opposed by the author and maintainer of the code, but it only goes so
far. If you are seen as needlessly blocking good work, those patches will
eventually flow around you and get into the mainline anyway. In the Linux
kernel, nobody has absolute veto power over any code. Except maybe Linus.
On very rare occasion, you may see something completely different: another
developer posts a different solution to your problem. At that point,
chances are that one of the two patches will not be merged, and "mine was
here first" is not considered to be a compelling technical argument. If
somebody else's patch displaces yours and gets into the mainline, there is
really only one way to respond: be pleased that your problem got solved and
get on with your work. Having one's work shoved aside in this manner can
be hurtful and discouraging, but the community will remember your reaction
long after they have forgotten whose patch actually got merged.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Patch를 게시한 뒤 작업이 시작된다
1-19Engineering 능력과 앞의 지침을 바탕으로 완벽해 보이는 patch series를 게시했더라도 작업이 끝났다고 생각해서는 안 된다. 경험 많은 kernel developer도 이 실수를 한다. Patch 게시 시점은 다음 단계로 넘어가는 지점이며 이후에도 상당한 작업이 남을 수 있다.
첫 게시에서 더 고칠 것이 전혀 없는 patch는 드물다. Kernel 개발 절차는 게시된 code를 개선하는 데 크게 의존한다. Author는 community와 협력해 code를 kernel 품질 기준에 맞춰야 하며 이 과정에 참여하지 않으면 mainline 포함이 어려워진다.
Reviewer는 5년과 10년 뒤의 유지보수를 본다
22-37의미 있는 patch에는 여러 developer의 review comment가 달린다. Reviewer가 patch의 가치와 작성 이유를 이해하더라도 5년 또는 10년 뒤 이 code를 포함한 kernel을 유지보수하는 일이 어떨지를 묻는다.
Coding style 수정부터 큰 rewrite까지 많은 요구는 Linux가 10년 뒤에도 계속 개발될 것이라는 전제에서 나온다.
표현보다 기술적 관찰에 집중하기
39-67Code review는 어렵고 보상받기 힘든 작업이다. 같은 실수를 반복해서 보면 reviewer가 날카롭게 반응할 수 있다. Review가 화나거나 모욕적으로 느껴져도 같은 방식으로 응답하지 않는다. Review 대상은 사람보다 code다.
Reviewer가 자기 고용주의 목표를 위해 경쟁사를 방해한다고 가정해서도 안 된다. Kernel developer는 고용주가 바뀔 수 있음을 알고 있으며 거의 예외 없이 가능한 한 좋은 kernel을 만들려는 목적을 갖는다.
사소해 보이는 coding style 변경이나 code를 공통 kernel 부분으로 분리하라는 요청에도 대비한다. Maintainer는 code의 일관성을 지켜야 하고 driver 안의 영리한 workaround가 다음 사용 사례를 위한 일반 kernel feature가 되어야 할 수도 있다.
Comment의 표현 방식이나 자존심 때문에 기술적 내용을 놓치지 않는다. Reviewer가 말하려는 바를 이해하고 가능한 항목은 고치며, review에 감사하고 질문에 어떻게 대응할지 답한다.
동의하지 않을 때 기술적으로 설명하기
69-83모든 제안에 동의할 필요는 없다. Reviewer가 code를 오해했다면 실제 동작을 설명하고, 제안에 기술적 반대가 있다면 이유와 자신의 해결책을 정당화한다.
설명이 설득력 있으면 reviewer도 받아들인다. 반대로 다른 사람까지 reviewer 의견에 동의한다면 자신의 해결책 때문에 근본 문제나 해결 대상 자체를 잘못 보고 있지 않은지 다시 생각한다.
Andrew Morton은 code 변경으로 이어지지 않은 review comment마다 code comment를 하나 추가하라고 제안했다. 그러면 미래 reviewer가 같은 질문을 반복하지 않게 할 수 있다.
Review를 무시하지 말고 changelog에 답을 남기기
85-97Review comment가 사라지기를 바라며 무시하는 것은 치명적인 실수다. 이전 comment에 답하지 않은 채 code를 다시 게시하면 patch는 진행되지 않을 가능성이 높다.
Reviewer는 이전 version의 세부 내용을 모두 기억하지 않는다. Repost할 때 이전에 제기된 문제와 해결 방법을 patch changelog에 정리한다. Reviewer가 mailing list archive를 직접 뒤지지 않게 하면 새 version을 더 효율적으로 검토할 수 있다.
기술적 교착의 조정
99-108대부분의 기술적 이견은 토론으로 해결되지만 누군가 결정을 내려야 할 때도 있다. 결정이 부당하다고 진지하게 판단한다면 더 높은 조정을 요청할 수 있다.
문서 작성 당시에는 Andrew Morton이 community의 존중을 바탕으로 막힌 상황을 자주 풀 수 있는 조정자였다. 하지만 다른 선택을 모두 시도하기 전에 가볍게 escalation해서는 안 되고 조정자가 자신의 의견에 동의하지 않을 가능성도 받아들여야 한다.
Subsystem tree와 linux-next
111-132Patch가 kernel에 유용하고 주요 review issue가 해결되면 보통 subsystem maintainer tree에 들어간다. Subsystem마다 방식이 다르고 다음 merge window용 tree와 장기 작업용 tree를 따로 둘 수 있다.
Memory management처럼 명확한 subsystem tree가 없는 영역이나 여러 subsystem에 걸친 patch는 -mm tree를 거칠 수 있다.
Subsystem tree에 들어가면 해당 tree를 쓰는 developer가 patch를 기본으로 받게 되고 대개 linux-next에도 포함되어 community 전체에 노출된다. 새로운 reviewer의 comment가 추가될 수 있으며 이전 round와 같은 방식으로 답해야 한다.
다른 tree와의 conflict 해결
134-143다른 developer의 작업과 conflict가 드러날 수 있다. 심한 경우 일부 patch를 미뤄 나머지를 먼저 정리하고 merge해야 한다. 다른 경우에는 관련 developer와 협력하고 patch를 tree 사이에서 옮겨 모두 cleanly apply되게 한다.
linux-next 이전에는 이런 conflict가 merge window에서야 발견되어 급히 고쳐야 했다. 이제는 merge window가 열리기 전에 여유 있게 해결할 수 있다.
Mainline merge 뒤에도 comment에 응답하기
145-162Patch가 mainline에 merge되면 축하할 일이지만 작업은 끝나지 않는다. MAINTAINERS file에 자신을 추가한 뒤에도 mainline 포함으로 생기는 새 책임이 있다.
더 많은 developer가 patch를 처음 보고 새로운 comment를 보낼 수 있다. 이미 merge되었다고 무시하지 말고 질문과 제안에 계속 응답한다.
더 중요한 변화는 훨씬 큰 tester 집단이 code를 사용한다는 점이다. 아직 널리 판매되지 않은 hardware driver도 예상보다 많은 사람이 kernel에 build하며 그에 따라 bug report가 생긴다.
Regression은 즉시 수정한다
164-179가장 심각한 report는 regression이다. 자신의 patch가 regression을 만들면 가능한 한 빨리 수정해야 한다. Author가 수정하지 못하고 다른 사람도 고치지 않으면 stabilization period 중 patch가 거의 확실히 제거된다.
Regression을 고치지 않아 patch가 제거되면 mainline에 넣기 위해 들인 작업이 무효가 되고 앞으로 다른 작업을 merge하기도 어려워질 수 있다.
Regression 뒤에는 일반 bug를 고친다. Stabilization period는 mainline release에 code가 처음 등장하기 전에 품질을 높일 가장 좋은 시기다. 기존 문제를 처리한 뒤 새 feature patch를 시작한다.
Release 이후 장기 유지보수
181-189다음 stable release나 주요 distribution이 해당 kernel version을 채택하는 시점에도 새 bug report가 생길 수 있다. 자신의 작업에 대한 기본적인 책임으로 계속 대응한다.
Community는 merge 뒤 code에 관심을 잃는 developer를 기억한다. 다음 patch를 평가할 때도 author가 향후 유지보수하지 않을 것이라는 가정을 하게 된다.
자신의 code에 들어온 patch 처리
192-209누군가 자신의 code에 patch를 보내는 것은 open development의 이점이다. 동의한다면 올바른 From: line으로 authorship을 보존하고 자신의 sign-off를 추가해 subsystem maintainer에게 전달하거나 Acked-by reply를 보내 original author가 전달하게 한다.
동의하지 않는다면 이유를 정중히 설명하고 가능하면 받아들일 수 있게 만들 변경을 알려 준다. Code author와 maintainer의 반대는 무게가 있지만 절대 veto는 아니다. 좋은 작업을 이유 없이 막는다고 보이면 patch는 결국 그 사람을 우회해 mainline에 들어갈 수 있다.
다른 해결책이 선택되었을 때
211-219다른 developer가 같은 문제에 별도 해결책을 게시하면 두 patch 중 하나만 merge될 가능성이 높다. 먼저 제출했다는 사실은 기술적으로 설득력 있는 근거가 아니다.
다른 patch가 자신의 patch를 대신해 mainline에 들어가면 문제가 해결된 것을 기쁘게 받아들이고 다음 작업으로 넘어간다. 작업이 밀려난 감정은 오래 남을 수 있지만 community는 어느 patch가 merge되었는지보다 그 상황에 어떻게 반응했는지를 더 오래 기억한다.
게시가 끝이 아닌 이유
6.Followthrough.rst:3-20완벽하게 준비한 patch series를 게시해도 작업이 끝난 것이 아니다. 첫 게시에서 개선할 점이 전혀 없는 patch는 드물며 커널 절차는 게시된 code를 반복적으로 개선하는 데 초점을 둔다.
Author는 community와 함께 code를 kernel quality standard에 맞춰야 한다. 이 과정에 참여하지 않으면 mainline에 포함되지 않을 가능성이 높다.