1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
List of reviewers, co-maintainers and how to submit fstests changes
====================================================
Please try to follow the guidelines below. This will make things
easier on the maintainers. Not all of these guidelines matter for every
trivial patch so apply some common sense.
Tips for patch submitters
-------------------------
1. Always *test* your changes, however small, on at least 4 or
5 people, preferably many more.
2. Make sure your changes compile correctly in multiple
configurations. In particular check that changes don't break
fstests basic running.
3. When you are happy with a change make it generally available for
testing and await feedback.
4. Make a patch available to fstests@ list directly, that's the only
one mailing list which maintain the whole fstests project.
PLEASE CC: the relevant reviewers, co-maintainers and mailing lists
that are generated by ``tools/get_maintainer.pl.``
PLEASE try to include any credit lines you want added with the
patch. It avoids people being missed off by mistake and makes
it easier to know who wants adding and who doesn't.
PLEASE document known bugs. If it doesn't work for everything
or does something very odd once a month document it.
5. Make sure you have the right to send any changes you make. If you
do changes at work you may find your employer owns the patch
not you.
6. Happy hacking.
Descriptions of section entries and preferred order
---------------------------------------------------
M: *Mail* patches to: FullName <address@domain>
These people might be a co-maintainer (with Supported status) or
maintainer (with Maintained status).
R: Designated *Reviewer*: FullName <address@domain>
These reviewers should be CCed on patches.
L: Besides fstests@ list itself, this *Mailing list* is relevant to
this area, should be CCed.
S: *Status*, one of the following (note: all things are maintained by
fstests@vger.kernel.org):
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it, has the privilege to
merge & push.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you
should be using that.
W: *Web-page* with status/info
Q: *Patchwork* web based patch tracking system site
B: URI for where to file *bugs*. A web-page with detailed bug
filing info, a direct bug tracker link, or a mailto: URI.
C: URI for *chat* protocol, server and channel where developers
usually hang out, for example irc://server/channel.
P: Subsystem Profile document for more details submitting
patches to the given subsystem. This is either an in-tree file,
or a URI.
T: *SCM* tree type and location.
Type is one of: git, hg, quilt, stgit, topgit
F: *Files* and directories wildcard patterns.
A trailing slash includes all files and subdirectory files.
F: tests/xfs/ all files in and below tests/xfs
F: tests/generic/* all files in tests/generic, but not below
F: */ext4/* all files in "any top level directory"/ext4
One pattern per line. Multiple F: lines acceptable.
X: *Excluded* files and directories that are NOT maintained, same
rules as F:. Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
F: src/
X: src/vfs
matches all files in and below net excluding net/ipv6/
N: Files and directories *Regex* patterns.
N: [^a-z]tegra all files whose path contains tegra
(not including files like integrator)
One pattern per line. Multiple N: lines acceptable.
tools/get_maintainer.pl has different behavior for files that
match F: pattern and matches of N: patterns. By default,
get_maintainer will not look at git log history when an F: pattern
match occurs. When an N: match occurs, git log history is used
to also notify the people that have git commit signatures.
K: *Content regex* (perl extended) pattern match in a patch or file.
For instance:
K: of_get_profile
matches patches or files that contain "of_get_profile"
K: \b(printk|pr_(info|err))\b
matches patches or files that contain one or more of the words
printk, pr_info or pr_err
One regex pattern per line. Multiple K: lines acceptable.
Maintainers List
----------------
.. note:: The whole fstests are maintained by fstests@vger.kernel.org, so you
should send patch to fstests@ at least. Other relevant mailing list
or reviewer or co-maintainer can be in cc list.
BTRFS
M: Anand Jain <anand.jain@oracle.com>
R: Filipe Manana <fdmanana@suse.com>
L: linux-btrfs@vger.kernel.org
S: Supported
F: tests/btrfs/
F: common/btrfs
CEPH
L: ceph-devel@vger.kernel.org
S: Supported
F: tests/ceph/
F: common/ceph
CIFS
L: linux-cifs@vger.kernel.org
S: Supported
F: tests/cifs
EXT4
L: linux-ext4@vger.kernel.org
S: Supported
F: tests/ext4/
F: common/ext4
F2FS
L: linux-f2fs-devel@lists.sourceforge.net
S: Supported
F: tests/f2fs/
F: common/f2fs
FSVERITY
R: Eric Biggers <ebiggers@google.com>
L: fsverity@lists.linux.dev
S: Supported
F: common/verity
FSCRYPT
R: Eric Biggers <ebiggers@google.com>
L: linux-fscrypt@vger.kernel.org
S: Supported
F: common/encrypt
NFS
L: linux-nfs@vger.kernel.org
S: Supported
F: tests/nfs/
F: common/nfs
OCFS2
L: ocfs2-devel@oss.oracle.com
S: Supported
F: tests/ocfs2/
OVERLAYFS
R: Amir Goldstein <amir73il@gmail.com>
L: linux-unionfs@vger.kernel.org
S: Supported
F: tests/overlay
F: common/overlay
UDF
R: Jan Kara <jack@suse.com>
S: Supported
F: tests/udf/
VFS
R: Christian Brauner <brauner@kernel.org>
L: linux-fsdevel@vger.kernel.org
S: Supported
F: src/vfs/
XFS
R: Darrick J. Wong <djwong@kernel.org>
L: linux-xfs@vger.kernel.org
S: Supported
F: common/dump
F: common/fuzzy
F: common/inject
F: common/populate
F: common/repair
F: common/xfs
F: tests/xfs/
ALL
M: Zorro Lang <zlang@kernel.org>
L: fstests@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
F: *
F: */
|
