filesystems/xfs/xfs-maintainer-entry-profile.rst

5 --------
6 XFS is a well known high-performance filesystem in the Linux kernel.
7 The aim of this project is to provide and maintain a robust and
10 Patches are generally merged to the for-next branch of the appropriate
12 After a testing period, the for-next branch is merged to the master
15 Kernel code are merged to the xfs-linux tree[0].
18 Ondisk format documentation are merged to the xfs-documentation tree[3].
21 list linux-xfs@vger.kernel.org.
24 -----
31 - **Outside Contributor**: Anyone who sends a patch but is not involved
36 - **Developer**: Someone who is familiar with the XFS codebase enough to
42 - **Senior Developer**: A developer who is very familiar with at least
43   some part of the XFS codebase and/or other subsystems in the kernel.
44   These people collectively decide the long term goals of the project
51 - **Reviewer**: Someone (most likely also a developer) who reads code
55   1. Does the idea fit the goals of the project?
63 - **Testing Lead**: This person is responsible for setting the test
64   coverage goals of the project, negotiating with developers to decide
69   the XFS section of the fstests MAINTAINERS file.
71 - **Bug Triager**: Someone who examines incoming bug reports in just
78 - **Release Manager**: This person merges reviewed patchsets into an
89 - **Community Manager**: This person calls and moderates meetings of as many
92   They may also serve as liaison between managers of the organizations
93   sponsoring work on any part of XFS.
95 - **LTS Maintainer**: Someone who backports and tests bug fixes from
105 -----------------------------
108 - Patches affecting only the filesystem itself should be based against
109   the latest -rc or the for-next branch.
110   These patches will be merged back to the for-next branch.
112 - Authors of patches touching other subsystems need to coordinate with
113   the maintainers of XFS and the relevant subsystems to decide how to
116 - Any patchset changing XFS should be cc'd in its entirety to linux-xfs.
117   Do not send partial patchsets; that makes analysis of the broader
118   context of the changes unnecessarily difficult.
120 - Anyone making kernel changes that have corresponding changes to the
124 - Authors of bug fix patches are expected to use fstests[2] to perform
125   an A/B test of the patch to determine that there are no regressions.
129 - Authors of new feature patchsets must ensure that fstests will have
130   appropriate functional and input corner-case test cases for the new
133 - When implementing a new feature, it is strongly suggested that the
145   * **What** userspace interfaces are necessary to build off of the new
157 - Patchsets for the new tests should be submitted as separate patchsets
160 - Changes to the on-disk format of XFS must be described in the ondisk
164 - Patchsets implementing bug fixes and further code cleanups should put
165   the bug fixes at the beginning of the series to ease backporting.
168 -----------------------
173 -rc1 and -rc6.
178 next merge window should be sent between -rc1 and -rc4.
183 --------------
186 developers that have Reviewed-by tags for XFS changes to take a look and
190 ----------
191 | [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/
192 | [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/
193 | [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/
194 | [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/