요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _maintainerentryprofile:
Maintainer Entry Profile
========================
The Maintainer Entry Profile supplements the top-level process documents
(submitting-patches, submitting drivers...) with
subsystem/device-driver-local customs as well as details about the patch
submission life-cycle. A contributor uses this document to level set
their expectations and avoid common mistakes; maintainers may use these
profiles to look across subsystems for opportunities to converge on
common practices.
Overview
--------
Provide an introduction to how the subsystem operates. While MAINTAINERS
tells the contributor where to send patches for which files, it does not
convey other subsystem-local infrastructure and mechanisms that aid
development.
Example questions to consider:
- Are there notifications when patches are applied to the local tree, or
merged upstream?
- Does the subsystem have a patchwork instance? Are patchwork state
changes notified?
- Any bots or CI infrastructure that watches the list, or automated
testing feedback that the subsystem uses to gate acceptance?
- Git branches that are pulled into -next?
- What branch should contributors submit against?
- Links to any other Maintainer Entry Profiles? For example a
device-driver may point to an entry for its parent subsystem. This makes
the contributor aware of obligations a maintainer may have for
other maintainers in the submission chain.
Submit Checklist Addendum
-------------------------
List mandatory and advisory criteria, beyond the common "submit-checklist",
for a patch to be considered healthy enough for maintainer attention.
For example: "pass checkpatch.pl with no errors, or warning. Pass the
unit test detailed at $URI".
The Submit Checklist Addendum can also include details about the status
of related hardware specifications. For example, does the subsystem
require published specifications at a certain revision before patches
will be considered.
Key Cycle Dates
---------------
One of the common misunderstandings of submitters is that patches can be
sent at any time before the merge window closes and can still be
considered for the next -rc1. The reality is that most patches need to
be settled in soaking in linux-next in advance of the merge window
opening. Clarify for the submitter the key dates (in terms of -rc release
week) that patches might be considered for merging and when patches need to
wait for the next -rc. At a minimum:
- Last -rc for new feature submissions:
New feature submissions targeting the next merge window should have
their first posting for consideration before this point. Patches that
are submitted after this point should be clear that they are targeting
the NEXT+1 merge window, or should come with sufficient justification
why they should be considered on an expedited schedule. A general
guideline is to set expectation with contributors that new feature
submissions should appear before -rc5.
- Last -rc to merge features: Deadline for merge decisions
Indicate to contributors the point at which an as yet un-applied patch
set will need to wait for the NEXT+1 merge window. Of course there is no
obligation to ever accept any given patchset, but if the review has not
concluded by this point the expectation is the contributor should wait and
resubmit for the following merge window.
Optional:
- First -rc at which the development baseline branch, listed in the
overview section, should be considered ready for new submissions.
Review Cadence
--------------
One of the largest sources of contributor angst is how soon to ping
after a patchset has been posted without receiving any feedback. In
addition to specifying how long to wait before a resubmission this
section can also indicate a preferred style of update like, resend the
full series, or privately send a reminder email. This section might also
list how review works for this code area and methods to get feedback
that are not directly from the maintainer.
Existing profiles
-----------------
For now, existing maintainer profiles are listed here; we will likely want
to do something different in the near future.
.. toctree::
:maxdepth: 1
../doc-guide/maintainer-profile
../nvdimm/maintainer-entry-profile
../arch/riscv/patch-acceptance
../process/maintainer-soc
../process/maintainer-soc-clean-dts
../driver-api/media/maintainer-entry-profile
../process/maintainer-netdev
../driver-api/vfio-pci-device-specific-driver-acceptance
../nvme/feature-and-quirk-policy
../filesystems/xfs/xfs-maintainer-entry-profile
../mm/damon/maintainer-profile
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Maintainer Entry Profile의 목적
1-14Maintainer Entry Profile은 `submitting-patches`, driver 제출 지침 같은 최상위 process 문서를 보완합니다. Subsystem 또는 device-driver 고유의 관행과 patch submission lifecycle 세부사항을 기록합니다.
Contributor는 profile로 기대 수준을 맞추고 흔한 실수를 피할 수 있습니다. Maintainer는 여러 subsystem의 profile을 비교해 공통 관행으로 수렴할 기회를 찾을 수 있습니다.
지역 규칙을 명시해 제출자와 maintainer의 암묵적 기대를 줄입니다.
.. _maintainerentryprofile:
Maintainer Entry Profile
========================
The Maintainer Entry Profile supplements the top-level process documents
(submitting-patches, submitting drivers...) with
subsystem/device-driver-local customs as well as details about the patch
submission life-cycle. A contributor uses this document to level set
their expectations and avoid common mistakes; maintainers may use these
profiles to look across subsystems for opportunities to converge on
common practices.
Overview에 포함할 정보
15-37Overview는 subsystem이 어떻게 운영되는지 소개해야 합니다. MAINTAINERS file은 어떤 file의 patch를 어디로 보낼지는 알려 주지만, 개발을 돕는 subsystem 고유 infrastructure와 mechanism까지 설명하지는 않습니다.
Profile은 local tree 적용 또는 upstream merge 때 notification이 오는지, patchwork instance가 있는지와 state 변경 notification 여부, list를 감시하는 bot·CI·자동 test feedback이 acceptance를 막는 gate로 쓰이는지를 설명할 수 있습니다.
또한 linux-next에 들어가는 Git branch, contributor가 기준으로 삼아 제출할 branch, parent subsystem이나 관련 driver의 다른 Maintainer Entry Profile link를 적어야 합니다. 이를 통해 submission chain의 다른 maintainer에 대한 의무도 알 수 있습니다.
Contributor가 patch를 보내기 전에 알아야 할 local workflow입니다.
Overview
--------
Provide an introduction to how the subsystem operates. While MAINTAINERS
tells the contributor where to send patches for which files, it does not
convey other subsystem-local infrastructure and mechanisms that aid
development.
Example questions to consider:
- Are there notifications when patches are applied to the local tree, or
merged upstream?
- Does the subsystem have a patchwork instance? Are patchwork state
changes notified?
- Any bots or CI infrastructure that watches the list, or automated
testing feedback that the subsystem uses to gate acceptance?
- Git branches that are pulled into -next?
- What branch should contributors submit against?
- Links to any other Maintainer Entry Profiles? For example a
device-driver may point to an entry for its parent subsystem. This makes
the contributor aware of obligations a maintainer may have for
other maintainers in the submission chain.
Submit Checklist Addendum
38-50이 절은 공통 `submit-checklist` 외에 maintainer가 검토할 수 있을 만큼 건강한 patch가 갖춰야 할 필수 조건과 권고 조건을 나열합니다.
예를 들어 `checkpatch.pl`을 error나 warning 없이 통과해야 한다거나, 특정 URI에 설명된 unit test를 통과해야 한다는 조건을 명시할 수 있습니다.
관련 hardware specification의 공개 상태도 포함할 수 있습니다. Subsystem이 patch 검토 전에 특정 revision 이상의 공개 specification을 요구하는지처럼 제출 가능성에 영향을 주는 조건을 적습니다.
공통 제출 규칙만으로 드러나지 않는 subsystem gate를 기록합니다.
Submit Checklist Addendum
-------------------------
List mandatory and advisory criteria, beyond the common "submit-checklist",
for a patch to be considered healthy enough for maintainer attention.
For example: "pass checkpatch.pl with no errors, or warning. Pass the
unit test detailed at $URI".
The Submit Checklist Addendum can also include details about the status
of related hardware specifications. For example, does the subsystem
require published specifications at a certain revision before patches
will be considered.
Key Cycle Dates
51-84제출자는 merge window가 닫히기 전이면 언제든 patch를 보내 다음 `-rc1`에 들어갈 수 있다고 오해하기 쉽습니다. 실제로 대부분의 patch는 merge window가 열리기 전에 linux-next에서 충분히 안정화되어야 합니다.
Profile은 `-rc` release week 기준으로 어느 시점까지 다음 merge window를 목표로 할 수 있고, 언제부터는 다음 cycle을 기다려야 하는지 명확히 해야 합니다.
새 feature 제출의 마지막 `-rc`는 다음 merge window를 목표로 한 최초 posting이 도착해야 하는 시점입니다. 그 뒤 제출한다면 `NEXT+1` merge window를 목표로 함을 밝히거나 expedited schedule이 필요한 충분한 이유를 제시해야 합니다. 일반적인 지침은 새 feature를 `-rc5` 전에 보내도록 기대를 설정하는 것입니다.
Feature merge 결정의 마지막 `-rc`도 알려야 합니다. 그 시점까지 review가 끝나지 않아 적용되지 않은 patchset은 acceptance 의무와 무관하게 다음 merge window를 기다렸다가 다시 제출해야 한다는 기대를 명확히 합니다.
선택 항목으로 Overview에 적은 development baseline branch가 새 submission을 받을 준비가 되는 첫 `-rc`도 지정할 수 있습니다.
최초 posting, review 완료, 다음 cycle 이월 시점을 분리합니다.
Key Cycle Dates
---------------
One of the common misunderstandings of submitters is that patches can be
sent at any time before the merge window closes and can still be
considered for the next -rc1. The reality is that most patches need to
be settled in soaking in linux-next in advance of the merge window
opening. Clarify for the submitter the key dates (in terms of -rc release
week) that patches might be considered for merging and when patches need to
wait for the next -rc. At a minimum:
- Last -rc for new feature submissions:
New feature submissions targeting the next merge window should have
their first posting for consideration before this point. Patches that
are submitted after this point should be clear that they are targeting
the NEXT+1 merge window, or should come with sufficient justification
why they should be considered on an expedited schedule. A general
guideline is to set expectation with contributors that new feature
submissions should appear before -rc5.
- Last -rc to merge features: Deadline for merge decisions
Indicate to contributors the point at which an as yet un-applied patch
set will need to wait for the NEXT+1 merge window. Of course there is no
obligation to ever accept any given patchset, but if the review has not
concluded by this point the expectation is the contributor should wait and
resubmit for the following merge window.
Optional:
- First -rc at which the development baseline branch, listed in the
overview section, should be considered ready for new submissions.
Review Cadence
85-94Contributor가 가장 불안해하는 지점 중 하나는 patchset을 보낸 뒤 feedback이 없을 때 언제 다시 연락해야 하는지입니다. Profile은 resubmission 전 대기 시간을 명시해야 합니다.
Update 방식도 안내할 수 있습니다. 전체 series를 다시 보내야 하는지, private reminder email을 보내는 것이 좋은지 등을 적습니다.
이 code 영역의 review가 어떤 방식으로 진행되는지와 maintainer에게 직접 요청하지 않고도 feedback을 얻을 방법을 함께 나열할 수 있습니다.
침묵 상태에서 contributor가 취할 다음 행동을 구체화합니다.
Review Cadence
--------------
One of the largest sources of contributor angst is how soon to ping
after a patchset has been posted without receiving any feedback. In
addition to specifying how long to wait before a resubmission this
section can also indicate a preferred style of update like, resend the
full series, or privately send a reminder email. This section might also
list how review works for this code area and methods to get feedback
that are not directly from the maintainer.
기존 profile 목록
95-114현재는 기존 maintainer profile을 이 절의 toctree에 직접 나열합니다. 앞으로는 다른 구성 방식으로 바뀔 가능성이 있습니다.
목록에는 documentation guide, NVDIMM, RISC-V patch acceptance, SoC와 clean DTS, media, netdev, VFIO PCI device-specific driver acceptance, NVMe feature·quirk policy, XFS, DAMON profile이 포함됩니다.
공통 template이 실제 subsystem별 문서에서 어떻게 구체화되는지 보여 줍니다.
Existing profiles
-----------------
For now, existing maintainer profiles are listed here; we will likely want
to do something different in the near future.
.. toctree::
:maxdepth: 1
../doc-guide/maintainer-profile
../nvdimm/maintainer-entry-profile
../arch/riscv/patch-acceptance
../process/maintainer-soc
../process/maintainer-soc-clean-dts
../driver-api/media/maintainer-entry-profile
../process/maintainer-netdev
../driver-api/vfio-pci-device-specific-driver-acceptance
../nvme/feature-and-quirk-policy
../filesystems/xfs/xfs-maintainer-entry-profile
../mm/damon/maintainer-profile
요약·해설
maintainer-entry-profile.rst:1-114Maintainer Entry Profile은 공통 process 문서에 없는 subsystem별 branch, automation, test, 일정, follow-up 규칙을 명시합니다.
Contributor는 review 가능 조건과 cycle 마감을 미리 알고, maintainer는 다른 subsystem과 관행을 비교해 공통 기준을 발전시킬 수 있습니다.