1 XFS Maintainer Entry Profile
2 ============================
3
4 Overview
5 --------
6 XFS is a well known high-performance filesyste
7 The aim of this project is to provide and main
8 performant filesystem.
9
10 Patches are generally merged to the for-next b
11 git repository.
12 After a testing period, the for-next branch is
13 branch.
14
15 Kernel code are merged to the xfs-linux tree[0
16 Userspace code are merged to the xfsprogs tree
17 Test cases are merged to the xfstests tree[2].
18 Ondisk format documentation are merged to the
19
20 All patchsets involving XFS *must* be cc'd in
21 list linux-xfs@vger.kernel.org.
22
23 Roles
24 -----
25 There are eight key roles in the XFS project.
26 A person can take on multiple roles, and a rol
27 multiple people.
28 Anyone taking on a role is advised to check in
29 others on a regular basis about burnout.
30
31 - **Outside Contributor**: Anyone who sends a
32 in the XFS project on a regular basis.
33 These folks are usually people who work on o
34 elsewhere in the kernel community.
35
36 - **Developer**: Someone who is familiar with
37 write new code, documentation, and tests.
38
39 Developers can often be found in the IRC cha
40 entry in the kernel MAINTAINERS file.
41
42 - **Senior Developer**: A developer who is ver
43 some part of the XFS codebase and/or other s
44 These people collectively decide the long te
45 and nudge the community in that direction.
46 They should help prioritize development and
47 cycle.
48
49 Senior developers tend to be more active par
50
51 - **Reviewer**: Someone (most likely also a de
52 submissions to decide:
53
54 0. Is the idea behind the contribution sound
55 1. Does the idea fit the goals of the projec
56 2. Is the contribution designed correctly?
57 3. Is the contribution polished?
58 4. Can the contribution be tested effectivel
59
60 Reviewers should identify themselves with an
61 and fstests MAINTAINERS files.
62
63 - **Testing Lead**: This person is responsible
64 coverage goals of the project, negotiating w
65 on new tests for new features, and making su
66 release managers execute on the testing.
67
68 The testing lead should identify themselves
69 the XFS section of the fstests MAINTAINERS f
70
71 - **Bug Triager**: Someone who examines incomi
72 enough detail to identify the person to whom
73 forwarded.
74
75 The bug triagers should identify themselves
76 the kernel MAINTAINERS file.
77
78 - **Release Manager**: This person merges revi
79 integration branch, tests the result locally
80 public git repository, and sends pull reques
81 The release manager is not expected to work
82 If a developer and a reviewer fail to reach
83 the release manager must have the ability to
84 resolution.
85
86 The release manager should identify themselv
87 the kernel MAINTAINERS file.
88
89 - **Community Manager**: This person calls and
90 XFS participants as they can get when mailin
91 insufficient for collective decisionmaking.
92 They may also serve as liaison between manag
93 sponsoring work on any part of XFS.
94
95 - **LTS Maintainer**: Someone who backports an
96 uptream to the LTS kernels.
97 There tend to be six separate LTS trees at a
98
99 The maintainer for a given LTS release shoul
100 ``M:`` entry in the MAINTAINERS file for tha
101 Unmaintained LTS kernels should be marked wi
102 same file.
103
104 Submission Checklist Addendum
105 -----------------------------
106 Please follow these additional rules when subm
107
108 - Patches affecting only the filesystem itself
109 the latest -rc or the for-next branch.
110 These patches will be merged back to the for
111
112 - Authors of patches touching other subsystems
113 the maintainers of XFS and the relevant subs
114 proceed with a merge.
115
116 - Any patchset changing XFS should be cc'd in
117 Do not send partial patchsets; that makes an
118 context of the changes unnecessarily difficu
119
120 - Anyone making kernel changes that have corre
121 userspace utilities should send the userspac
122 patchsets immediately after the kernel patch
123
124 - Authors of bug fix patches are expected to u
125 an A/B test of the patch to determine that t
126 When possible, a new regression test case sh
127 fstests.
128
129 - Authors of new feature patchsets must ensure
130 appropriate functional and input corner-case
131 feature.
132
133 - When implementing a new feature, it is stron
134 developers write a design document to answer
135
136 * **What** problem is this trying to solve?
137
138 * **Who** will benefit from this solution, a
139 access it?
140
141 * **How** will this new feature work? This
142 structures and algorithms supporting the s
143 than code comments.
144
145 * **What** userspace interfaces are necessar
146 features?
147
148 * **How** will this work be tested to ensure
149 problems laid out in the design document w
150 problems?
151
152 The design document should be committed in t
153 directory.
154 It may be omitted if the feature is already
155 community.
156
157 - Patchsets for the new tests should be submit
158 immediately after the kernel and userspace c
159
160 - Changes to the on-disk format of XFS must be
161 format document[3] and submitted as a patchs
162 patchsets.
163
164 - Patchsets implementing bug fixes and further
165 the bug fixes at the beginning of the series
166
167 Key Release Cycle Dates
168 -----------------------
169 Bug fixes may be sent at any time, though the
170 defer a patch when the next merge window is cl
171
172 Code submissions targeting the next merge wind
173 -rc1 and -rc6.
174 This gives the community time to review the ch
175 and for the author to retest those changes.
176
177 Code submissions also requiring changes to fs/
178 next merge window should be sent between -rc1
179 This allows the broader kernel community adequ
180 infrastructure changes.
181
182 Review Cadence
183 --------------
184 In general, please wait at least one week befo
185 To find reviewers, either consult the MAINTAIN
186 developers that have Reviewed-by tags for XFS
187 offer their opinion.
188
189 References
190 ----------
191 | [0] https://git.kernel.org/pub/scm/fs/xfs/xf
192 | [1] https://git.kernel.org/pub/scm/fs/xfs/xf
193 | [2] https://git.kernel.org/pub/scm/fs/xfs/xf
194 | [3] https://git.kernel.org/pub/scm/fs/xfs/xf
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.