요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
==============================
Feature and driver maintainers
==============================
The term "maintainer" spans a very wide range of levels of engagement
from people handling patches and pull requests as almost a full time job
to people responsible for a small feature or a driver.
Unlike most of the chapter, this section is meant for the latter (more
populous) group. It provides tips and describes the expectations and
responsibilities of maintainers of a small(ish) section of the code.
Drivers and alike most often do not have their own mailing lists and
git trees but instead send and review patches on the list of a larger
subsystem.
Responsibilities
================
The amount of maintenance work is usually proportional to the size
and popularity of the code base. Small features and drivers should
require relatively small amount of care and feeding. Nonetheless
when the work does arrive (in form of patches which need review,
user bug reports etc.) it has to be acted upon promptly.
Even when a particular driver only sees one patch a month, or a quarter,
a subsystem could well have a hundred such drivers. Subsystem
maintainers cannot afford to wait a long time to hear from reviewers.
The exact expectations on the response time will vary by subsystem.
The patch review SLA the subsystem had set for itself can sometimes
be found in the subsystem documentation. Failing that as a rule of thumb
reviewers should try to respond quicker than what is the usual patch
review delay of the subsystem maintainer. The resulting expectations
may range from two working days for fast-paced subsystems (e.g. networking)
to as long as a few weeks in slower moving parts of the kernel.
Mailing list participation
--------------------------
Linux kernel uses mailing lists as the primary form of communication.
Maintainers must be subscribed and follow the appropriate subsystem-wide
mailing list. Either by subscribing to the whole list or using more
modern, selective setup like
`lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_.
Maintainers must know how to communicate on the list (plain text, no invasive
legal footers, no top posting, etc.)
Reviews
-------
Maintainers must review *all* patches touching exclusively their drivers,
no matter how trivial. If the patch is a tree wide change and modifies
multiple drivers - whether to provide a review is left to the maintainer.
When there are multiple maintainers for a piece of code an ``Acked-by``
or ``Reviewed-by`` tag (or review comments) from a single maintainer is
enough to satisfy this requirement.
If the review process or validation for a particular change will take longer
than the expected review timeline for the subsystem, maintainer should
reply to the submission indicating that the work is being done, and when
to expect full results.
Refactoring and core changes
----------------------------
Occasionally core code needs to be changed to improve the maintainability
of the kernel as a whole. Maintainers are expected to be present and
help guide and test changes to their code to fit the new infrastructure.
Bug reports
-----------
Maintainers must ensure severe problems in their code reported to them
are resolved in a timely manner: regressions, kernel crashes, kernel warnings,
compilation errors, lockups, data loss, and other bugs of similar scope.
Maintainers furthermore should respond to reports about other kinds of
bugs as well, if the report is of reasonable quality or indicates a
problem that might be severe -- especially if they have *Supported*
status of the codebase in the MAINTAINERS file.
Open development
----------------
Discussions about user reported issues, and development of new code
should be conducted in a manner typical for the larger subsystem.
It is common for development within a single company to be conducted
behind closed doors. However, development and discussions initiated
by community members must not be redirected from public to closed forums
or to private email conversations. Reasonable exceptions to this guidance
include discussions about security related issues.
Selecting the maintainer
========================
The previous section described the expectations of the maintainer,
this section provides guidance on selecting one and describes common
misconceptions.
The author
----------
Most natural and common choice of a maintainer is the author of the code.
The author is intimately familiar with the code, so it is the best person
to take care of it on an ongoing basis.
That said, being a maintainer is an active role. The MAINTAINERS file
is not a list of credits (in fact a separate CREDITS file exists),
it is a list of those who will actively help with the code.
If the author does not have the time, interest or ability to maintain
the code, a different maintainer must be selected.
Multiple maintainers
--------------------
Modern best practices dictate that there should be at least two maintainers
for any piece of code, no matter how trivial. It spreads the burden, helps
people take vacations and prevents burnout, trains new members of
the community etc. etc. Even when there is clearly one perfect candidate,
another maintainer should be found.
Maintainers must be human, therefore, it is not acceptable to add a mailing
list or a group email as a maintainer. Trust and understanding are the
foundation of kernel maintenance and one cannot build trust with a mailing
list. Having a mailing list *in addition* to humans is perfectly fine.
Corporate structures
--------------------
To an outsider the Linux kernel may resemble a hierarchical organization
with Linus as the CEO. While the code flows in a hierarchical fashion,
the corporate template does not apply here. Linux is an anarchy held
together by (rarely expressed) mutual respect, trust and convenience.
All that is to say that managers almost never make good maintainers.
The maintainer position more closely matches an on-call rotation
than a position of power.
The following characteristics of a person selected as a maintainer
are clear red flags:
- unknown to the community, never sent an email to the list before
- did not author any of the code
- (when development is contracted) works for a company which paid
for the development rather than the company which did the work
Non compliance
==============
Subsystem maintainers may remove inactive maintainers from the MAINTAINERS
file. If the maintainer was a significant author or played an important
role in the development of the code, they should be moved to the CREDITS file.
Removing an inactive maintainer should not be seen as a punitive action.
Having an inactive maintainer has a real cost as all developers have
to remember to include the maintainers in discussions and subsystem
maintainers spend brain power figuring out how to solicit feedback.
Subsystem maintainers may remove code for lacking maintenance.
Subsystem maintainers may refuse accepting code from companies
which repeatedly neglected their maintainership duties.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Feature·driver maintainer의 범위
1-18`maintainer`라는 말은 patch와 pull request를 거의 전업으로 처리하는 사람부터 작은 feature나 driver 하나를 맡는 사람까지 매우 넓은 참여 수준을 포함합니다.
이 문서는 그중 인원이 더 많은 후자, 즉 비교적 작은 code 영역의 maintainer를 대상으로 합니다. 해당 역할에 기대되는 책임과 실무 조언을 설명합니다.
Driver와 비슷한 작은 영역은 자체 mailing list나 Git tree를 갖지 않는 경우가 많습니다. 대신 상위 subsystem의 mailing list에서 patch를 보내고 review합니다. 따라서 작은 영역의 maintainer도 subsystem 전체의 흐름 안에서 활동해야 합니다.
Code 소유 범위는 작아도 협업 통로는 상위 subsystem과 공유합니다.
.. SPDX-License-Identifier: GPL-2.0
==============================
Feature and driver maintainers
==============================
The term "maintainer" spans a very wide range of levels of engagement
from people handling patches and pull requests as almost a full time job
to people responsible for a small feature or a driver.
Unlike most of the chapter, this section is meant for the latter (more
populous) group. It provides tips and describes the expectations and
responsibilities of maintainers of a small(ish) section of the code.
Drivers and alike most often do not have their own mailing lists and
git trees but instead send and review patches on the list of a larger
subsystem.
책임과 응답 시간
19-38유지보수 작업량은 보통 codebase의 크기와 인기에 비례합니다. 작은 feature나 driver는 평소 관리 부담이 적지만, review할 patch나 user bug report가 도착하면 신속하게 처리해야 합니다.
Driver 하나에는 한 달이나 한 분기에 patch 하나만 올 수 있어도 subsystem에는 그런 driver가 백 개 있을 수 있습니다. Subsystem maintainer가 각 reviewer의 답을 오래 기다릴 여유는 없습니다.
구체적인 응답 시간 기대치는 subsystem마다 다릅니다. Subsystem 문서에 patch review SLA가 있으면 이를 따릅니다. 없다면 reviewer는 subsystem maintainer의 통상 review 지연보다 더 빨리 응답하려고 해야 합니다.
빠르게 움직이는 networking 같은 subsystem에서는 두 working day 정도일 수 있고, 느린 kernel 영역에서는 몇 주까지 허용될 수 있습니다. 핵심은 자신의 작은 code 영역이 상위 queue를 막지 않게 하는 것입니다.
고정된 전역 SLA 대신 subsystem 속도에 맞춥니다.
Responsibilities
================
The amount of maintenance work is usually proportional to the size
and popularity of the code base. Small features and drivers should
require relatively small amount of care and feeding. Nonetheless
when the work does arrive (in form of patches which need review,
user bug reports etc.) it has to be acted upon promptly.
Even when a particular driver only sees one patch a month, or a quarter,
a subsystem could well have a hundred such drivers. Subsystem
maintainers cannot afford to wait a long time to hear from reviewers.
The exact expectations on the response time will vary by subsystem.
The patch review SLA the subsystem had set for itself can sometimes
be found in the subsystem documentation. Failing that as a rule of thumb
reviewers should try to respond quicker than what is the usual patch
review delay of the subsystem maintainer. The resulting expectations
may range from two working days for fast-paced subsystems (e.g. networking)
to as long as a few weeks in slower moving parts of the kernel.
Mailing list 참여와 review
39-66Linux kernel은 mailing list를 기본 소통 수단으로 사용합니다. Maintainer는 적절한 subsystem 전체 mailing list를 구독하고 따라야 합니다. 전체 list를 구독하거나 `lei` 같은 현대적인 선택적 수집 방식을 사용할 수 있습니다.
List에서는 plain text, 과도한 법적 footer 금지, top posting 금지 등 kernel mailing list의 기본 소통 방식을 알아야 합니다.
Maintainer는 아무리 사소해 보여도 자신의 driver만을 건드리는 모든 patch를 review해야 합니다. 여러 driver를 바꾸는 tree-wide change는 review할지 maintainer가 판단할 수 있습니다.
한 code 영역에 maintainer가 여러 명이면 한 명이 남긴 `Acked-by`, `Reviewed-by`, 또는 review comment만으로 이 의무를 충족할 수 있습니다.
특정 변경의 review나 validation이 subsystem의 예상 기간보다 오래 걸린다면, 제출자에게 작업 중임을 알리고 전체 결과를 언제 제공할지 답해야 합니다. 침묵 대신 상태와 예상 시점을 공유하는 것이 책임의 일부입니다.
빠른 최종 결론이 어렵더라도 접수와 진행 상태는 제때 알립니다.
Mailing list participation
--------------------------
Linux kernel uses mailing lists as the primary form of communication.
Maintainers must be subscribed and follow the appropriate subsystem-wide
mailing list. Either by subscribing to the whole list or using more
modern, selective setup like
`lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_.
Maintainers must know how to communicate on the list (plain text, no invasive
legal footers, no top posting, etc.)
Reviews
-------
Maintainers must review *all* patches touching exclusively their drivers,
no matter how trivial. If the patch is a tree wide change and modifies
multiple drivers - whether to provide a review is left to the maintainer.
When there are multiple maintainers for a piece of code an ``Acked-by``
or ``Reviewed-by`` tag (or review comments) from a single maintainer is
enough to satisfy this requirement.
If the review process or validation for a particular change will take longer
than the expected review timeline for the subsystem, maintainer should
reply to the submission indicating that the work is being done, and when
to expect full results.
Core 변화·bug report·공개 개발
67-96Kernel 전체의 유지보수성을 높이기 위해 core code를 바꿔야 할 때가 있습니다. Maintainer는 자신의 code가 새 infrastructure에 맞도록 변경 방향을 안내하고 test하는 데 참여해야 합니다.
자신의 code에서 보고된 regression, kernel crash, kernel warning, compilation error, lockup, data loss와 비슷한 심각한 문제는 적시에 해결되도록 해야 합니다.
그 밖의 bug도 report 품질이 합리적이거나 심각할 가능성이 있으면 응답해야 합니다. 특히 MAINTAINERS file에서 codebase 상태가 `Supported`라면 이 기대가 더 강합니다.
사용자 issue 논의와 새 code 개발은 상위 subsystem의 일반적인 공개 방식으로 진행해야 합니다. 회사 내부 개발이 비공개로 이루어지는 경우가 있더라도 community member가 시작한 개발과 논의를 폐쇄 forum이나 private email로 돌려서는 안 됩니다.
Security issue 논의처럼 합리적인 예외는 허용됩니다. 공개 개발 원칙은 민감한 취약점의 비공개 조정까지 금지한다는 의미가 아닙니다.
심각도와 공개 협업 원칙을 함께 적용합니다.
Refactoring and core changes
----------------------------
Occasionally core code needs to be changed to improve the maintainability
of the kernel as a whole. Maintainers are expected to be present and
help guide and test changes to their code to fit the new infrastructure.
Bug reports
-----------
Maintainers must ensure severe problems in their code reported to them
are resolved in a timely manner: regressions, kernel crashes, kernel warnings,
compilation errors, lockups, data loss, and other bugs of similar scope.
Maintainers furthermore should respond to reports about other kinds of
bugs as well, if the report is of reasonable quality or indicates a
problem that might be severe -- especially if they have *Supported*
status of the codebase in the MAINTAINERS file.
Open development
----------------
Discussions about user reported issues, and development of new code
should be conducted in a manner typical for the larger subsystem.
It is common for development within a single company to be conducted
behind closed doors. However, development and discussions initiated
by community members must not be redirected from public to closed forums
or to private email conversations. Reasonable exceptions to this guidance
include discussions about security related issues.
Maintainer 선정과 원저자
97-116가장 자연스럽고 흔한 maintainer 후보는 code 작성자입니다. 작성자는 code를 잘 알고 있으므로 장기적으로 돌보기에 유리합니다.
하지만 maintainer는 능동적인 역할입니다. MAINTAINERS file은 공로자 명단이 아니며, 공로 기록에는 별도의 CREDITS file이 있습니다. MAINTAINERS에는 앞으로도 code를 적극적으로 도울 사람을 적습니다.
작성자에게 유지보수할 시간, 관심, 능력이 없다면 다른 maintainer를 선정해야 합니다. 과거 기여의 크기만으로 현재 책임자를 정해서는 안 됩니다.
Code 이해도는 강점이지만 현재 활동 가능성이 필수 조건입니다.
Selecting the maintainer
========================
The previous section described the expectations of the maintainer,
this section provides guidance on selecting one and describes common
misconceptions.
The author
----------
Most natural and common choice of a maintainer is the author of the code.
The author is intimately familiar with the code, so it is the best person
to take care of it on an ongoing basis.
That said, being a maintainer is an active role. The MAINTAINERS file
is not a list of credits (in fact a separate CREDITS file exists),
it is a list of those who will actively help with the code.
If the author does not have the time, interest or ability to maintain
the code, a different maintainer must be selected.
복수 maintainer와 사람 중심 책임
117-130현대적인 모범 사례는 code가 아무리 작아도 maintainer를 최소 두 명 두는 것입니다. 부담을 나누고 휴가를 가능하게 하며 burnout을 줄이고 community의 새 구성원을 훈련하는 데 도움이 됩니다.
한 명의 완벽한 후보가 명확해 보여도 다른 maintainer를 찾아야 합니다. 단일 담당자에게 지식과 응답 의무가 집중되는 위험을 줄이기 위해서입니다.
Maintainer는 사람이어야 하므로 mailing list나 group email을 maintainer로 등록하는 것은 허용되지 않습니다. Kernel maintenance의 기반인 신뢰와 이해는 익명의 list를 상대로 형성할 수 없습니다. 사람 maintainer에 더해 mailing list를 등록하는 것은 괜찮습니다.
응답 지속성과 신뢰 관계를 동시에 확보합니다.
Multiple maintainers
--------------------
Modern best practices dictate that there should be at least two maintainers
for any piece of code, no matter how trivial. It spreads the burden, helps
people take vacations and prevents burnout, trains new members of
the community etc. etc. Even when there is clearly one perfect candidate,
another maintainer should be found.
Maintainers must be human, therefore, it is not acceptable to add a mailing
list or a group email as a maintainer. Trust and understanding are the
foundation of kernel maintenance and one cannot build trust with a mailing
list. Having a mailing list *in addition* to humans is perfectly fine.
기업 조직과 다른 maintainer 역할
131-150외부에서 보면 Linux kernel이 Linus를 CEO로 둔 계층 조직처럼 보일 수 있습니다. Code가 계층적으로 흘러가기는 하지만 기업 조직의 template은 적용되지 않습니다. Linux는 상호 존중, 신뢰, 편의로 유지되는 분산 협업 구조입니다.
따라서 manager가 좋은 maintainer가 되는 경우는 드뭅니다. Maintainer는 권력의 자리가 아니라 on-call rotation에 더 가까운 실무 책임입니다.
후보가 community에 알려지지 않았고 list에 email을 보낸 적이 없거나, 해당 code를 전혀 작성하지 않았거나, 계약 개발에서 실제 개발 회사가 아니라 비용을 지불한 회사 소속이라는 점은 명확한 warning sign입니다.
직급이나 계약 관계보다 community 참여와 실제 code 경험을 봅니다.
Corporate structures
--------------------
To an outsider the Linux kernel may resemble a hierarchical organization
with Linus as the CEO. While the code flows in a hierarchical fashion,
the corporate template does not apply here. Linux is an anarchy held
together by (rarely expressed) mutual respect, trust and convenience.
All that is to say that managers almost never make good maintainers.
The maintainer position more closely matches an on-call rotation
than a position of power.
The following characteristics of a person selected as a maintainer
are clear red flags:
- unknown to the community, never sent an email to the list before
- did not author any of the code
- (when development is contracted) works for a company which paid
for the development rather than the company which did the work
책임 불이행 처리
151-166Subsystem maintainer는 활동하지 않는 maintainer를 MAINTAINERS file에서 제거할 수 있습니다. 그 사람이 중요한 작성자이거나 code 발전에 큰 역할을 했다면 CREDITS file로 옮기는 것이 적절합니다.
비활동 maintainer 제거는 처벌로 보면 안 됩니다. 모든 개발자가 계속 그 사람을 discussion에 포함해야 하고 subsystem maintainer가 feedback을 얻을 방법을 고민해야 하므로, 비활동 entry는 실제 비용을 만듭니다.
유지보수가 부족하면 subsystem maintainer는 해당 code를 제거할 수도 있습니다. 유지보수 의무를 반복해서 소홀히 하는 회사의 새 code를 받지 않는 결정도 가능합니다.
공로 기록과 현재 책임 명단을 분리합니다.
Non compliance
==============
Subsystem maintainers may remove inactive maintainers from the MAINTAINERS
file. If the maintainer was a significant author or played an important
role in the development of the code, they should be moved to the CREDITS file.
Removing an inactive maintainer should not be seen as a punitive action.
Having an inactive maintainer has a real cost as all developers have
to remember to include the maintainers in discussions and subsystem
maintainers spend brain power figuring out how to solicit feedback.
Subsystem maintainers may remove code for lacking maintenance.
Subsystem maintainers may refuse accepting code from companies
which repeatedly neglected their maintainership duties.
요약·해설
feature-and-driver-maintainers.rst:1-166작은 driver의 평소 작업량이 적어도 patch와 심각한 bug가 오면 subsystem 일정에 맞춰 신속히 응답해야 합니다.
Maintainer는 공개 mailing list에서 review와 개발을 이어가며, 현재 활동 가능한 사람을 최소 두 명 두는 것이 권장됩니다.
MAINTAINERS는 공로 명단이 아니라 현재 책임 명단이므로 비활동 담당자는 필요하면 CREDITS로 옮겨야 합니다.