요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
XFS Maintainer Entry Profile
============================
Overview
--------
XFS is a well known high-performance filesystem in the Linux kernel.
The aim of this project is to provide and maintain a robust and
performant filesystem.
Patches are generally merged to the for-next branch of the appropriate
git repository.
After a testing period, the for-next branch is merged to the master
branch.
Kernel code are merged to the xfs-linux tree[0].
Userspace code are merged to the xfsprogs tree[1].
Test cases are merged to the xfstests tree[2].
Ondisk format documentation are merged to the xfs-documentation tree[3].
All patchsets involving XFS *must* be cc'd in their entirety to the mailing
list linux-xfs@vger.kernel.org.
Roles
-----
There are eight key roles in the XFS project.
A person can take on multiple roles, and a role can be filled by
multiple people.
Anyone taking on a role is advised to check in with themselves and
others on a regular basis about burnout.
- **Outside Contributor**: Anyone who sends a patch but is not involved
in the XFS project on a regular basis.
These folks are usually people who work on other filesystems or
elsewhere in the kernel community.
- **Developer**: Someone who is familiar with the XFS codebase enough to
write new code, documentation, and tests.
Developers can often be found in the IRC channel mentioned by the ``C:``
entry in the kernel MAINTAINERS file.
- **Senior Developer**: A developer who is very familiar with at least
some part of the XFS codebase and/or other subsystems in the kernel.
These people collectively decide the long term goals of the project
and nudge the community in that direction.
They should help prioritize development and review work for each release
cycle.
Senior developers tend to be more active participants in the IRC channel.
- **Reviewer**: Someone (most likely also a developer) who reads code
submissions to decide:
0. Is the idea behind the contribution sound?
1. Does the idea fit the goals of the project?
2. Is the contribution designed correctly?
3. Is the contribution polished?
4. Can the contribution be tested effectively?
Reviewers should identify themselves with an ``R:`` entry in the kernel
and fstests MAINTAINERS files.
- **Testing Lead**: This person is responsible for setting the test
coverage goals of the project, negotiating with developers to decide
on new tests for new features, and making sure that developers and
release managers execute on the testing.
The testing lead should identify themselves with an ``M:`` entry in
the XFS section of the fstests MAINTAINERS file.
- **Bug Triager**: Someone who examines incoming bug reports in just
enough detail to identify the person to whom the report should be
forwarded.
The bug triagers should identify themselves with a ``B:`` entry in
the kernel MAINTAINERS file.
- **Release Manager**: This person merges reviewed patchsets into an
integration branch, tests the result locally, pushes the branch to a
public git repository, and sends pull requests further upstream.
The release manager is not expected to work on new feature patchsets.
If a developer and a reviewer fail to reach a resolution on some point,
the release manager must have the ability to intervene to try to drive a
resolution.
The release manager should identify themselves with an ``M:`` entry in
the kernel MAINTAINERS file.
- **Community Manager**: This person calls and moderates meetings of as many
XFS participants as they can get when mailing list discussions prove
insufficient for collective decisionmaking.
They may also serve as liaison between managers of the organizations
sponsoring work on any part of XFS.
- **LTS Maintainer**: Someone who backports and tests bug fixes from
upstream to the LTS kernels.
There tend to be six separate LTS trees at any given time.
The maintainer for a given LTS release should identify themselves with an
``M:`` entry in the MAINTAINERS file for that LTS tree.
Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that
same file.
Submission Checklist Addendum
-----------------------------
Please follow these additional rules when submitting to XFS:
- Patches affecting only the filesystem itself should be based against
the latest -rc or the for-next branch.
These patches will be merged back to the for-next branch.
- Authors of patches touching other subsystems need to coordinate with
the maintainers of XFS and the relevant subsystems to decide how to
proceed with a merge.
- Any patchset changing XFS should be cc'd in its entirety to linux-xfs.
Do not send partial patchsets; that makes analysis of the broader
context of the changes unnecessarily difficult.
- Anyone making kernel changes that have corresponding changes to the
userspace utilities should send the userspace changes as separate
patchsets immediately after the kernel patchsets.
- Authors of bug fix patches are expected to use fstests[2] to perform
an A/B test of the patch to determine that there are no regressions.
When possible, a new regression test case should be written for
fstests.
- Authors of new feature patchsets must ensure that fstests will have
appropriate functional and input corner-case test cases for the new
feature.
- When implementing a new feature, it is strongly suggested that the
developers write a design document to answer the following questions:
* **What** problem is this trying to solve?
* **Who** will benefit from this solution, and **where** will they
access it?
* **How** will this new feature work? This should touch on major data
structures and algorithms supporting the solution at a higher level
than code comments.
* **What** userspace interfaces are necessary to build off of the new
features?
* **How** will this work be tested to ensure that it solves the
problems laid out in the design document without causing new
problems?
The design document should be committed in the kernel documentation
directory.
It may be omitted if the feature is already well known to the
community.
- Patchsets for the new tests should be submitted as separate patchsets
immediately after the kernel and userspace code patchsets.
- Changes to the on-disk format of XFS must be described in the ondisk
format document[3] and submitted as a patchset after the fstests
patchsets.
- Patchsets implementing bug fixes and further code cleanups should put
the bug fixes at the beginning of the series to ease backporting.
Key Release Cycle Dates
-----------------------
Bug fixes may be sent at any time, though the release manager may decide to
defer a patch when the next merge window is close.
Code submissions targeting the next merge window should be sent between
-rc1 and -rc6.
This gives the community time to review the changes, to suggest other changes,
and for the author to retest those changes.
Code submissions also requiring changes to fs/iomap and targeting the
next merge window should be sent between -rc1 and -rc4.
This allows the broader kernel community adequate time to test the
infrastructure changes.
Review Cadence
--------------
In general, please wait at least one week before pinging for feedback.
To find reviewers, either consult the MAINTAINERS file, or ask
developers that have Reviewed-by tags for XFS changes to take a look and
offer their opinion.
References
----------
| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/
| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/
| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/
| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
프로젝트 목표와 repository별 merge 흐름
1-22XFS는 Linux kernel의 잘 알려진 고성능 filesystem이며, project의 목표는 견고하고 성능 좋은 filesystem을 제공하고 유지하는 것입니다.
Patch는 일반적으로 해당 git repository의 `for-next` branch에 merge됩니다. 일정한 testing 기간이 지나면 `for-next`가 `master` branch로 merge됩니다.
Kernel code는 `xfs-linux` tree[0], userspace code는 `xfsprogs` tree[1], test case는 `xfstests` tree[2], on-disk format 문서는 `xfs-documentation` tree[3]에 merge됩니다.
XFS와 관련된 모든 patchset은 일부가 아니라 전체를 `linux-xfs@vger.kernel.org` mailing list에 반드시 CC해야 합니다. 원문의 `must`는 선택적 권고가 아니라 필수 규칙입니다.
Patch 종류에 따라 integration tree가 다릅니다.
각 repository에서 같은 integration 단계를 따릅니다.
XFS Maintainer Entry Profile
============================
Overview
--------
XFS is a well known high-performance filesystem in the Linux kernel.
The aim of this project is to provide and maintain a robust and
performant filesystem.
Patches are generally merged to the for-next branch of the appropriate
git repository.
After a testing period, the for-next branch is merged to the master
branch.
Kernel code are merged to the xfs-linux tree[0].
Userspace code are merged to the xfsprogs tree[1].
Test cases are merged to the xfstests tree[2].
Ondisk format documentation are merged to the xfs-documentation tree[3].
All patchsets involving XFS *must* be cc'd in their entirety to the mailing
list linux-xfs@vger.kernel.org.
Contributor·Developer·Senior Developer
23-50원문은 XFS project에 핵심 역할이 여덟 개라고 서술하지만, 실제로 뒤에서 열거하는 role은 아홉 개입니다. 한 사람이 여러 role을 맡을 수 있고 한 role을 여러 사람이 맡을 수도 있습니다. 역할을 맡는 사람은 burnout 여부를 자신과 동료에게 정기적으로 확인하도록 권고받습니다.
`Outside Contributor`는 patch를 보내지만 XFS project에 정기적으로 참여하지 않는 사람입니다. 보통 다른 filesystem이나 kernel community의 다른 영역에서 일합니다.
`Developer`는 새 code, documentation, test를 작성할 만큼 XFS codebase에 익숙한 사람입니다. Developer는 kernel `MAINTAINERS` file의 `C:` entry에 적힌 IRC channel에서 흔히 찾을 수 있습니다.
`Senior Developer`는 XFS codebase 일부 또는 다른 kernel subsystem에 매우 익숙한 developer입니다. 이들은 함께 project의 장기 목표를 정하고 community가 그 방향으로 나아가게 하며, release cycle마다 development와 review 우선순위를 정하는 데 도움을 줘야 합니다. IRC channel에도 더 적극적으로 참여하는 편입니다.
정기 참여 수준과 project 방향에 대한 책임이 점차 커집니다.
Roles
-----
There are eight key roles in the XFS project.
A person can take on multiple roles, and a role can be filled by
multiple people.
Anyone taking on a role is advised to check in with themselves and
others on a regular basis about burnout.
- **Outside Contributor**: Anyone who sends a patch but is not involved
in the XFS project on a regular basis.
These folks are usually people who work on other filesystems or
elsewhere in the kernel community.
- **Developer**: Someone who is familiar with the XFS codebase enough to
write new code, documentation, and tests.
Developers can often be found in the IRC channel mentioned by the ``C:``
entry in the kernel MAINTAINERS file.
- **Senior Developer**: A developer who is very familiar with at least
some part of the XFS codebase and/or other subsystems in the kernel.
These people collectively decide the long term goals of the project
and nudge the community in that direction.
They should help prioritize development and review work for each release
cycle.
Senior developers tend to be more active participants in the IRC channel.
Reviewer·Testing Lead·Bug Triager·Release Manager
51-88`Reviewer`는 code submission을 읽어 기여의 기본 idea가 타당한지, project 목표에 맞는지, design이 올바른지, 충분히 다듬어졌는지, 효과적으로 test할 수 있는지를 판단합니다. Reviewer는 kernel과 fstests `MAINTAINERS` file의 `R:` entry로 자신을 표시해야 합니다.
`Testing Lead`는 project의 test coverage 목표를 정하고 새 feature에 필요한 test를 developer와 협의하며, developer와 release manager가 실제 testing을 수행하도록 책임집니다. Fstests `MAINTAINERS` file XFS 절의 `M:` entry로 표시해야 합니다.
`Bug Triager`는 들어오는 bug report를 필요한 만큼 조사해 어느 담당자에게 전달할지 식별합니다. Kernel `MAINTAINERS` file의 `B:` entry로 자신을 표시해야 합니다.
`Release Manager`는 review된 patchset을 integration branch에 merge하고 local test 후 public git repository에 push하며 상위로 pull request를 보냅니다. 새 feature patchset을 직접 개발할 것으로 기대되지는 않습니다. Developer와 reviewer가 쟁점을 해결하지 못하면 해결을 이끌기 위해 개입할 수 있어야 하며, kernel `MAINTAINERS`의 `M:` entry로 표시합니다.
각 역할의 책임과 공식 entry를 연결합니다.
- **Reviewer**: Someone (most likely also a developer) who reads code
submissions to decide:
0. Is the idea behind the contribution sound?
1. Does the idea fit the goals of the project?
2. Is the contribution designed correctly?
3. Is the contribution polished?
4. Can the contribution be tested effectively?
Reviewers should identify themselves with an ``R:`` entry in the kernel
and fstests MAINTAINERS files.
- **Testing Lead**: This person is responsible for setting the test
coverage goals of the project, negotiating with developers to decide
on new tests for new features, and making sure that developers and
release managers execute on the testing.
The testing lead should identify themselves with an ``M:`` entry in
the XFS section of the fstests MAINTAINERS file.
- **Bug Triager**: Someone who examines incoming bug reports in just
enough detail to identify the person to whom the report should be
forwarded.
The bug triagers should identify themselves with a ``B:`` entry in
the kernel MAINTAINERS file.
- **Release Manager**: This person merges reviewed patchsets into an
integration branch, tests the result locally, pushes the branch to a
public git repository, and sends pull requests further upstream.
The release manager is not expected to work on new feature patchsets.
If a developer and a reviewer fail to reach a resolution on some point,
the release manager must have the ability to intervene to try to drive a
resolution.
The release manager should identify themselves with an ``M:`` entry in
the kernel MAINTAINERS file.
Community Manager와 LTS Maintainer
89-103`Community Manager`는 mailing-list discussion만으로 collective decision을 내리기 어려울 때 가능한 많은 XFS participant를 모아 meeting을 소집하고 진행합니다. XFS 관련 작업을 후원하는 organization의 manager 사이에서 liaison 역할을 할 수도 있습니다.
`LTS Maintainer`는 upstream bug fix를 LTS kernel에 backport하고 test합니다. 일반적으로 어느 시점이든 별도의 LTS tree가 여섯 개 정도 존재합니다.
각 LTS release maintainer는 해당 LTS tree의 `MAINTAINERS` file에 `M:` entry로 자신을 표시해야 합니다. 유지되지 않는 LTS kernel은 같은 file에서 status를 `S: Orphan`으로 표시해야 합니다.
기술 patch flow 바깥의 조정과 backport 책임입니다.
- **Community Manager**: This person calls and moderates meetings of as many
XFS participants as they can get when mailing list discussions prove
insufficient for collective decisionmaking.
They may also serve as liaison between managers of the organizations
sponsoring work on any part of XFS.
- **LTS Maintainer**: Someone who backports and tests bug fixes from
upstream to the LTS kernels.
There tend to be six separate LTS trees at any given time.
The maintainer for a given LTS release should identify themselves with an
``M:`` entry in the MAINTAINERS file for that LTS tree.
Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that
same file.
Patch 기반·CC·userspace·test 규칙
104-132Filesystem 자체만 바꾸는 patch는 최신 `-rc` 또는 `for-next` branch를 기준으로 작성해야 하며 다시 `for-next`로 merge됩니다.
다른 subsystem도 건드리는 patch 작성자는 XFS maintainer와 해당 subsystem maintainer에게 merge 진행 방식을 조율해야 합니다.
XFS를 변경하는 모든 patchset은 전체를 `linux-xfs`에 CC해야 합니다. 일부 patch만 보내면 전체 변경 context 분석이 불필요하게 어려워지므로 partial patchset은 보내지 않습니다.
Kernel 변경과 대응하는 userspace utility 변경이 있으면 kernel patchset 바로 다음에 별도의 userspace patchset으로 제출해야 합니다.
Bug-fix patch 작성자는 `fstests`[2]로 patch 적용 전후 A/B test를 수행해 regression이 없음을 확인해야 합니다. 가능하면 fstests에 새 regression test case도 작성해야 합니다.
새 feature patchset 작성자는 fstests에 해당 기능의 적절한 functional test와 input corner-case test가 준비되도록 보장해야 합니다.
서로 대응하는 변경도 별도 patchset으로 이어서 제출합니다.
Submission Checklist Addendum
-----------------------------
Please follow these additional rules when submitting to XFS:
- Patches affecting only the filesystem itself should be based against
the latest -rc or the for-next branch.
These patches will be merged back to the for-next branch.
- Authors of patches touching other subsystems need to coordinate with
the maintainers of XFS and the relevant subsystems to decide how to
proceed with a merge.
- Any patchset changing XFS should be cc'd in its entirety to linux-xfs.
Do not send partial patchsets; that makes analysis of the broader
context of the changes unnecessarily difficult.
- Anyone making kernel changes that have corresponding changes to the
userspace utilities should send the userspace changes as separate
patchsets immediately after the kernel patchsets.
- Authors of bug fix patches are expected to use fstests[2] to perform
an A/B test of the patch to determine that there are no regressions.
When possible, a new regression test case should be written for
fstests.
- Authors of new feature patchsets must ensure that fstests will have
appropriate functional and input corner-case test cases for the new
feature.
Design 문서와 patch series 배열
133-166새 feature를 구현할 때 developer가 design document를 작성할 것을 강하게 권고합니다. 문서는 어떤 문제를 해결하는지, 누가 어디서 이 solution을 사용하는지, 주요 data structure와 algorithm 수준에서 어떻게 동작하는지, 어떤 userspace interface가 필요한지, 새 문제 없이 목표를 달성했음을 어떻게 test할지를 답해야 합니다.
Design document는 kernel documentation directory에 commit해야 합니다. 다만 feature가 community에 이미 잘 알려져 있다면 생략할 수 있습니다.
새 test patchset은 kernel과 userspace code patchset 바로 다음에 별도 series로 제출해야 합니다.
XFS on-disk format 변경은 on-disk format document[3]에 설명하고 fstests patchset 다음에 별도 patchset으로 제출해야 합니다.
Bug fix와 후속 code cleanup을 함께 구현하는 patchset은 backport가 쉽도록 series 앞부분에 bug fix를 배치해야 합니다.
Code comment보다 높은 수준의 설계 근거를 남깁니다.
각 산출물은 별도 patchset이지만 전체 context를 연속해 제공합니다.
- When implementing a new feature, it is strongly suggested that the
developers write a design document to answer the following questions:
* **What** problem is this trying to solve?
* **Who** will benefit from this solution, and **where** will they
access it?
* **How** will this new feature work? This should touch on major data
structures and algorithms supporting the solution at a higher level
than code comments.
* **What** userspace interfaces are necessary to build off of the new
features?
* **How** will this work be tested to ensure that it solves the
problems laid out in the design document without causing new
problems?
The design document should be committed in the kernel documentation
directory.
It may be omitted if the feature is already well known to the
community.
- Patchsets for the new tests should be submitted as separate patchsets
immediately after the kernel and userspace code patchsets.
- Changes to the on-disk format of XFS must be described in the ondisk
format document[3] and submitted as a patchset after the fstests
patchsets.
- Patchsets implementing bug fixes and further code cleanups should put
the bug fixes at the beginning of the series to ease backporting.
Release cycle 제출 시점
167-181Bug fix는 언제든 보낼 수 있지만 다음 merge window가 가까우면 release manager가 patch를 다음 cycle로 미룰 수 있습니다.
다음 merge window를 목표로 하는 일반 code submission은 `-rc1`과 `-rc6` 사이에 보내야 합니다. 이 기간은 community가 변경을 review하고 추가 변경을 제안하며 author가 이를 다시 test할 시간을 제공합니다.
`fs/iomap` 변경도 필요한 submission은 더 넓은 kernel community가 infrastructure 변경을 충분히 test할 수 있도록 `-rc1`과 `-rc4` 사이에 보내야 합니다.
Infrastructure 영향이 넓을수록 더 이른 마감이 적용됩니다.
Key Release Cycle Dates
-----------------------
Bug fixes may be sent at any time, though the release manager may decide to
defer a patch when the next merge window is close.
Code submissions targeting the next merge window should be sent between
-rc1 and -rc6.
This gives the community time to review the changes, to suggest other changes,
and for the author to retest those changes.
Code submissions also requiring changes to fs/iomap and targeting the
next merge window should be sent between -rc1 and -rc4.
This allows the broader kernel community adequate time to test the
infrastructure changes.
Feedback 요청 간격과 reviewer 찾기
182-188일반적으로 feedback을 재촉하기 전에 최소 1주일을 기다려야 합니다.
Reviewer를 찾으려면 `MAINTAINERS` file을 확인하거나, 이전 XFS 변경에 `Reviewed-by` tag를 준 developer에게 검토와 의견을 요청합니다.
Reviewer의 시간을 존중하면서 적절한 담당자를 찾습니다.
Review Cadence
--------------
In general, please wait at least one week before pinging for feedback.
To find reviewers, either consult the MAINTAINERS file, or ask
developers that have Reviewed-by tags for XFS changes to take a look and
offer their opinion.
공식 repository 참조
189-194참조 [0]부터 [3]은 각각 kernel, userspace utility, test suite, on-disk format documentation의 공식 XFS git repository를 가리킵니다. URL은 자동화와 검증에 사용할 수 있도록 원문 그대로 유지합니다.
Overview의 tree 번호와 실제 주소를 연결합니다.
References
----------
| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/
| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/
| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/
| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/
요약·해설
xfs-maintainer-entry-profile.rst:1-194XFS project의 repository, integration branch, mailing-list 의무, 참여 역할, test와 design 요구, patchset 배열, release-cycle deadline, review cadence를 정의합니다. 특히 모든 XFS patchset 전체를 linux-xfs에 CC해야 하며 kernel·userspace·test·format 문서는 별도 repository와 patchset으로 연속 제출합니다.
규범 강도가 높은 항목을 빠르게 점검합니다.