fstests: add MAINTAINERS and get_maintainer.pl files

As fstests covers more and more fs testing, so we always get help
from fs specific mailing list, due to they learn about their features
and bugs more. Besides that, some folks help to review patches
(relevant with them) more often.

So I'd like to bring in the similar way of linux/MAINTAINERS, records
fs relevant mailing lists, reviewers or co-maintainers. To recognize
the contribution from them, and help more users to know who or what
mailing list can be added in CC list of a patch.

The MAINTAINERS and get_maintainer.pl are copied from linux project,
then made some changes for fstests specially.

Signed-off-by: Zorro Lang <zlang@kernel.org>

1 files changed, 116 insertions, 0 deletions

diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 00000000..22a04d2f
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,116 @@
+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.
+
+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:	*/