Documentation/doc-guide/maintainer-profile.rst GitHub 원문 ↗

Linux 6.18.37 · Documentation Guide

Documentation Subsystem Maintainer Entry Profile

커널 문서 subsystem의 범위, patch 제출 checklist, merge 주기와 검토 응답 방식을 설명합니다.

Source pathDocumentation/doc-guide/maintainer-profile.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

maintainer-profile.rst:1-52

커널 문서 subsystem의 범위, patch 제출 checklist, merge 주기와 검토 응답 방식을 설명합니다. 영어 원문 전체와 한국어 전문 번역을 함께 제공하며 함수명, symbol, source path, e-mail, 명령, ReST 역할과 원문 줄 좌표를 보존합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 .. SPDX-License-Identifier: GPL-2.0
2
3 Documentation subsystem maintainer entry profile
4 ================================================
5
6 The documentation "subsystem" is the central coordinating point for the
7 kernel's documentation and associated infrastructure. It covers the
8 hierarchy under Documentation/ (with the exception of
9 Documentation/devicetree), various utilities under scripts/ and, at least
10 some of the time, LICENSES/.
11
12 It's worth noting, though, that the boundaries of this subsystem are rather
13 fuzzier than normal. Many other subsystem maintainers like to keep control
14 of portions of Documentation/, and many more freely apply changes there
15 when it is convenient. Beyond that, much of the kernel's documentation is
16 found in the source as kerneldoc comments; those are usually (but not
17 always) maintained by the relevant subsystem maintainer.
18
19 The mailing list for documentation is linux-doc@vger.kernel.org. Patches
20 should be made against the docs-next tree whenever possible.
21
22 Submit checklist addendum
23 -------------------------
24
25 When making documentation changes, you should actually build the
26 documentation and ensure that no new errors or warnings have been
27 introduced. Generating HTML documents and looking at the result will help
28 to avoid unsightly misunderstandings about how things will be rendered.
29
30 All new documentation (including additions to existing documents) should
31 ideally justify who the intended target audience is somewhere in the
32 changelog; this way, we ensure that the documentation ends up in the correct
33 place. Some possible categories are: kernel developers (experts or
34 beginners), userspace programmers, end users and/or system administrators,
35 and distributors.
36
37 Key cycle dates
38 ---------------
39
40 Patches can be sent anytime, but response will be slower than usual during
41 the merge window. The docs tree tends to close late before the merge
42 window opens, since the risk of regressions from documentation patches is
43 low.
44
45 Review cadence
46 --------------
47
48 I am the sole maintainer for the documentation subsystem, and I am doing
49 the work on my own time, so the response to patches will occasionally be
50 slow. I try to always send out a notification when a patch is merged (or
51 when I decide that one cannot be). Do not hesitate to send a ping if you
52 have not heard back within a week of sending a patch.
53

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

문서 subsystem의 범위와 협업 경로

1-20

이 문서는 `GPL-2.0` 라이선스를 따르는 Documentation subsystem maintainer entry profile입니다. 문서 `subsystem`은 커널 문서와 관련 기반 시설을 중앙에서 조정하는 지점입니다. `Documentation/devicetree`를 제외한 `Documentation/` 아래 계층, `scripts/` 아래의 여러 utility, 그리고 때에 따라 `LICENSES/`까지 다룹니다.

다만 이 subsystem의 경계는 보통의 subsystem보다 모호합니다. 많은 다른 subsystem maintainer가 `Documentation/` 일부에 대한 제어권을 유지하려 하고, 더 많은 maintainer가 필요할 때 그곳에 직접 변경을 적용합니다. 또한 커널 문서의 상당 부분은 소스의 kerneldoc 주석에 있으며, 보통은 관련 subsystem maintainer가 이를 관리하지만 항상 그런 것은 아닙니다.

문서 mailing list는 `linux-doc@vger.kernel.org`입니다. 가능하면 patch는 `docs-next` tree를 기준으로 작성해야 합니다.

제출 checklist 추가 사항

21-35

문서를 변경할 때는 실제로 문서를 build하고 새로운 error나 warning이 생기지 않았는지 확인해야 합니다. HTML 문서를 생성해 결과를 직접 살펴보면 렌더링 방식을 잘못 이해해 보기 흉한 결과를 만드는 일을 피할 수 있습니다.

기존 문서에 대한 추가 내용을 포함해 모든 새 문서는 changelog 어딘가에서 의도한 대상 독자가 누구인지 설명하는 것이 바람직합니다. 그래야 문서가 올바른 위치에 배치됩니다. 대상 범주의 예로는 숙련자 또는 초보자인 kernel developer, userspace programmer, end user와 system administrator, distributor가 있습니다.

주요 개발 주기 시점

36-44

patch는 언제든 보낼 수 있지만 merge window 동안에는 평소보다 응답이 느립니다. 문서 patch가 regression을 일으킬 위험은 낮기 때문에 docs tree는 merge window가 열리기 직전까지 비교적 늦게 닫히는 경향이 있습니다.

검토 주기와 재문의

45-52

문서 subsystem에는 maintainer가 한 명뿐이고 개인 시간을 들여 작업하므로 patch 응답이 때때로 느릴 수 있습니다. maintainer는 patch를 merge했거나 merge할 수 없다고 판단했을 때 항상 알림을 보내려고 합니다. patch를 보낸 뒤 일주일 안에 회신을 받지 못했다면 주저하지 말고 ping을 보내도 됩니다.