[igt-dev] [RFC i-g-t 1/1] MAINTAINERS: Introduce MAINTAINERS file

Petri Latvala petri.latvala at intel.com
Thu Feb 3 11:03:56 UTC 2022


On Mon, Jan 31, 2022 at 09:28:18AM -0500, Rodrigo Siqueira wrote:
> IGT is growing in terms of new vendors actively using it. Right now, we
> only have Intel CI to validate new patches, which can create a situation
> where bugs get accidentally introduced to other vendors. To alleviate
> this problem and also making easy for other developers to be aware of
> some specific changes, I'm proposing the introduction of the MAINTAINERS
> file as the one used in the Linux kernel. With this approach, we can
> have multiple enginers from different companies as reviewers for
> specific tests, and contributors should use get_maintainers script to
> find the right people to address their changes.
> 
> Cc: Arkadiusz Hiler <arek at hiler.eu>
> Cc: Petri Latvala <petri.latvala at intel.com>
> Cc: Mark Yacoub <markyacoub at google.com>
> Cc: Jessica Zhang <quic_jesszhan at quicinc.com>
> Cc: Abhinav Kumar <quic_abhinavk at quicinc.com>
> Cc: Melissa Wen <mwen at igalia.com>
> Cc: Sean Paul <seanpaul at chromium.org>
> Cc: Harry Wentland <harry.wentland at amd.com>
> Cc: Sun Peng Li(Leo) <sunpeng.li at amd.com>
> Cc: Chao-kai Wang (Stylon) <stylon.wang at amd.com>
> Cc: Wayne Lin <wayne.lin at amd.com>
> Cc: Nicholas Choi <nicholas.choi at amd.com>
> Cc: Martin Peres <martin.peres at mupuf.org>
> Cc: Aurabindo Pillai <aurabindo.pillai at amd.com>
> Cc: Bhawanpreet Lakha <bhawanpreet.lakha at amd.com>
> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo at amd.com>
> Cc: Solomon Chiu <solomon.chiu at amd.com>
> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>


A tentative ack on this effort from me, for getting more contact
points formally documented.

As for the implementation of it, I know this is copied from the kernel
so I know the reason why they're there, but reduce the useless
complexity in the documentation comment like the type of version
control in a subtree, and things that just aren't true for IGT, like
asking for testing from 4 or 5 people.

(Not to mention you're using S to describe the people, whereas the
original usage in kernel is to describe the files)

And the scripting to use this should be contained within
IGT. get_maintainer.pl is GPL-2.0 so we could in theory just copy
it. It isn't used to produce binaries so IGT should still remain
distributable with MIT terms but IANAL...


-- 
Petri Latvala


> ---
>  MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 201 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 383c327c..3529a689 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1,2 +1,201 @@
> -Petri Latvala <petri.latvala at intel.com>
> -Arkadiusz Hiler <arek at hiler.eu>
> +List of maintainers and how to submit IGT 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.
> +
> +3.	When you are happy with a change make it generally available for
> +	testing and await feedback.
> +
> +4.	Make a patch available to the relevant maintainer in the list. Use
> +	``diff -u`` to make the patch easy to merge. Be prepared to get your
> +	changes sent back with seemingly silly requests about formatting
> +	and variable names.  These aren't as silly as they seem. One
> +	job the maintainers do is to keep things looking the same.
> +
> +	PLEASE CC: the maintainers and mailing lists that are generated
> +	by ``scripts/get_maintainer.pl.`` The results returned by the
> +	script will be best if you have git installed.
> +
> +	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.
> +
> +	PLEASE remember that submissions must be made under the terms
> +	of the Linux Foundation certificate of contribution and should
> +	include a Signed-off-by: line.  The current version of this
> +	"Developer's Certificate of Origin" (DCO) is listed in the file
> +	Documentation/process/submitting-patches.rst.
> +
> +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 at domain>
> +	R: Designated *Reviewer*: FullName <address at domain>
> +	   These reviewers should be CCed on patches.
> +	L: *Mailing list* that is relevant to this area
> +	S: *Status*, one of the following:
> +	   Supported:	Someone is actually paid to look after this.
> +	   Maintained:	Someone actually looks after it.
> +	   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. See Documentation/maintainer/maintainer-entry-profile.rst
> +	   for details.
> +	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/amdgpu/	all files in and below tests/amdgpu
> +	   F:	tests/*	all files in tests/, but not below
> +	   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.
> +	N: Files and directories *Regex* patterns.
> +	   One pattern per line.  Multiple N: lines acceptable.
> +	   scripts/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"
> +	   One regex pattern per line.  Multiple K: lines acceptable.
> +
> +Maintainers List
> +----------------
> +
> +.. note:: When reading this list, please look for the most precise areas
> +          first. When adding to this list, please keep the entries in
> +          alphabetical order.
> +
> +KMS Generic API tests
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> +S:	Odd Fixes
> +F:	tests/kms_atomic.c
> +F:	tests/kms_atomic_interruptible.c
> +F:	tests/kms_atomic_transition.c
> +F:	tests/kms_properties.c
> +F:	tests/kms_setmode.c
> +F:	tests/kms_concurrent.c
> +F:	tests/kms_prop_blob.c
> +F:	tests/kms_multipipe_modeset.c
> +
> +KMS CRC API
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> +F:	tests/kms_cursor_crc.c
> +F:	tests/kms_pipe_crc_basic.c
> +F:	tests/kms_atomic.c
> +F:	tests/kms_rotation_crc.c
> +
> +KMS HDR
> +R:	Bhawanpreet Lakha <bhawanpreet.lakha at amd.com>
> +F:	tests/kms_hdr.c
> +
> +KMS Color
> +R:	Stylon Wang <stylon.wang at amd.com>
> +F:	tests/kms_multipipe_modeset.c
> +
> +KMS Content protection
> +R:	Stylon Wang <stylon.wang at amd.com>
> +R:	Bhawanpreet Lakha <bhawanpreet.lakha at amd.com>
> +F:	tests/kms_content_protection.c
> +
> +KMS Cursor tests
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> +S:	Odd Fixes
> +F:	tests/kms_cursor_legacy.c
> +F:	tests/kms_cursor_edge_walk.c
> +F:	tests/kms_plane_cursor.c
> +F:	tests/kms_plane_alpha_blend.c
> +
> +VRR tests
> +R:	Wayne Lin <Wayne.Lin at amd.com>
> +S:	Maintained
> +F:	tests/kms_vblank.c
> +
> +KMS Vblank tests
> +R:	Aurabindo Pillai <aurabindo.pillai at amd.com>
> +S:	Maintained
> +F:	tests/kms_vblank.c
> +
> +KMS Flip tests
> +R:	Aurabindo Pillai <aurabindo.pillai at amd.com>
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> +S:	Maintained
> +F:	tests/kms_flip.c
> +F:	tests/kms_flip_event_leak.c
> +
> +KMS plane tests
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> +S:	Maintained
> +S:	Maintained
> +F:	tests/kms_plane.c
> +F:	tests/kms_plane_scaling.c
> +
> +AMDGPU
> +M:	Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> +M:	Stylon Wang <stylon.wang at amd.com>
> +M:	Wayne Lin <Wayne.Lin at amd.com>
> +S:	Maintained
> +F:	tests/amdgpu/*
> +
> +AMDGPU AMD Plane
> +M:	Bhawanpreet Lakha <bhawanpreet.lakha at amd.com>
> +F:	tests/amdgpu/amd_plane.c
> +
> +AMDGPU AMD Color
> +M:	Wayne Lin <Wayne.Lin at amd.com>
> +F:	tests/amdgpu/amd_color.c
> +F:	tests/amdgpu/amd_max_bpc.c
> +
> +AMDGPU AMD content protection
> +M:	Stylon Wang <stylon.wang at amd.com>
> +M:	Bhawanpreet Lakha <bhawanpreet.lakha at amd.com>
> +F:	tests/amdgpu/amd_assr.c
> +
> +All KMS tests
> +R:	Mark Yacoub <markyacoub at chromium.org>
> +F:	tests/kms_*
> +
> +THE REST
> +M:	Arkadiusz Hiler <arek at hiler.eu>
> +M:	Petri Latvala <petri.latvala at intel.com>
> +L:	Development mailing list for IGT GPU Tools <igt-dev at lists.freedesktop.org>
> +S:	Buried alive in reporters
> +Q:	https://patchwork.freedesktop.org/project/igt/series/?ordering=-last_updated
> +T:	git at gitlab.freedesktop.org:drm/igt-gpu-tools.git
> +F:	*
> +F:	*/
> -- 
> 2.25.1
> 


More information about the igt-dev mailing list