[igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[Rodrigo Siqueira]

Hi,

IGT is becoming more generic, and multiple vendors are adopting it. For
example, AMD fully upstream all of its internal changes last year, and
now we are relying on IGT from the upstream. Additionally, thanks to the
ChromeOS project, we have other vendors working on the KMS tests as
well. At this point, I believe that we need some mechanism to better
contact developers that care about some specific tests or even provide an
easy way for other people to find the right stakeholder for dealing with
some particular issue.

Imho Linux Kernel already has a good solution codified in the
MAINTAINERS and get_maintainers files. One of the best things about this
approach was adding reviewers and maintainers (and other options) to the
specific part of the code and using the get_maintainers tool to extract
the right people to be part of the series. With this idea in mind, I
created this RFC that introduces the MAINTAINERS file in IGT, and I have
already added some entries to this file. My approach was:

* Petri and Hiler are the maintainers, and for this reason, their
  contact will be displayed for every patch.
* I add Mark Yacoub as a reviewer for every KMS test.
* I added some AMD folks as reviewers in some specific KMS tests that we
  run in our CI.
* I added some AMD maintainers to amdgpu tests.

If you want to try it in your local repository, you will need the
get_maintainers script from the Linux kernel, and you can use this
command:

 perl /PATH/TO/get_maintainer.pl --no-tree --separator , --nokeywords --nogit --nogit-fallback --norolestats -f <TARGET_TEST>

Anyway, this is just an idea that I want to discuss with the community.
What do you think about having a MAINTAINERs file? Do you want to add
your name as a reviewer to some specific test if you like the idea? Any
other comments or ideas?

Cc: Arkadiusz Hiler <arek@hiler.eu>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Mark Yacoub <markyacoub@google.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Melissa Wen <mwen@igalia.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Cc: Nicholas Choi <nicholas.choi@amd.com>
Cc: Martin Peres <martin.peres@mupuf.org>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
Cc: Solomon Chiu <solomon.chiu@amd.com>

Best Regards,
Siqueira

Rodrigo Siqueira (1):
  MAINTAINERS: Introduce MAINTAINERS file

 MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 201 insertions(+), 2 deletions(-)

-- 
2.25.1

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

[Rodrigo Siqueira]

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@hiler.eu>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Mark Yacoub <markyacoub@google.com>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Melissa Wen <mwen@igalia.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
Cc: Wayne Lin <wayne.lin@amd.com>
Cc: Nicholas Choi <nicholas.choi@amd.com>
Cc: Martin Peres <martin.peres@mupuf.org>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
Cc: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
---
 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@intel.com>
-Arkadiusz Hiler <arek@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@domain>
+	R: Designated *Reviewer*: FullName <address@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@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@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@amd.com>
+F:	tests/kms_hdr.c
+
+KMS Color
+R:	Stylon Wang <stylon.wang@amd.com>
+F:	tests/kms_multipipe_modeset.c
+
+KMS Content protection
+R:	Stylon Wang <stylon.wang@amd.com>
+R:	Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
+F:	tests/kms_content_protection.c
+
+KMS Cursor tests
+R:	Rodrigo Siqueira <Rodrigo.Siqueira@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@amd.com>
+S:	Maintained
+F:	tests/kms_vblank.c
+
+KMS Vblank tests
+R:	Aurabindo Pillai <aurabindo.pillai@amd.com>
+S:	Maintained
+F:	tests/kms_vblank.c
+
+KMS Flip tests
+R:	Aurabindo Pillai <aurabindo.pillai@amd.com>
+R:	Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+S:	Maintained
+F:	tests/kms_flip.c
+F:	tests/kms_flip_event_leak.c
+
+KMS plane tests
+R:	Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+S:	Maintained
+S:	Maintained
+F:	tests/kms_plane.c
+F:	tests/kms_plane_scaling.c
+
+AMDGPU
+M:	Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+M:	Stylon Wang <stylon.wang@amd.com>
+M:	Wayne Lin <Wayne.Lin@amd.com>
+S:	Maintained
+F:	tests/amdgpu/*
+
+AMDGPU AMD Plane
+M:	Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
+F:	tests/amdgpu/amd_plane.c
+
+AMDGPU AMD Color
+M:	Wayne Lin <Wayne.Lin@amd.com>
+F:	tests/amdgpu/amd_color.c
+F:	tests/amdgpu/amd_max_bpc.c
+
+AMDGPU AMD content protection
+M:	Stylon Wang <stylon.wang@amd.com>
+M:	Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
+F:	tests/amdgpu/amd_assr.c
+
+All KMS tests
+R:	Mark Yacoub <markyacoub@chromium.org>
+F:	tests/kms_*
+
+THE REST
+M:	Arkadiusz Hiler <arek@hiler.eu>
+M:	Petri Latvala <petri.latvala@intel.com>
+L:	Development mailing list for IGT GPU Tools <igt-dev@lists.freedesktop.org>
+S:	Buried alive in reporters
+Q:	https://patchwork.freedesktop.org/project/igt/series/?ordering=-last_updated
+T:	git@gitlab.freedesktop.org:drm/igt-gpu-tools.git
+F:	*
+F:	*/
-- 
2.25.1

Re: [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[Sean Paul]

On Mon, Jan 31, 2022 at 9:29 AM Rodrigo Siqueira
<Rodrigo.Siqueira@amd.com> wrote:
>
> Hi,
>
> IGT is becoming more generic, and multiple vendors are adopting it. For
> example, AMD fully upstream all of its internal changes last year, and
> now we are relying on IGT from the upstream. Additionally, thanks to the
> ChromeOS project, we have other vendors working on the KMS tests as
> well. At this point, I believe that we need some mechanism to better
> contact developers that care about some specific tests or even provide an
> easy way for other people to find the right stakeholder for dealing with
> some particular issue.
>

Hi Siqueira,
Do you have a sense for how much of this is necessary once igt
transitions to gitlab merge requests (or what it looks like in that
new reality)? IIRC the reason igt is not using MR's is because of some
CI infrastructure only talking mailing list, I was under the
impression that was changing and MR's were the way forward.

Sean

> Imho Linux Kernel already has a good solution codified in the
> MAINTAINERS and get_maintainers files. One of the best things about this
> approach was adding reviewers and maintainers (and other options) to the
> specific part of the code and using the get_maintainers tool to extract
> the right people to be part of the series. With this idea in mind, I
> created this RFC that introduces the MAINTAINERS file in IGT, and I have
> already added some entries to this file. My approach was:
>
> * Petri and Hiler are the maintainers, and for this reason, their
>   contact will be displayed for every patch.
> * I add Mark Yacoub as a reviewer for every KMS test.
> * I added some AMD folks as reviewers in some specific KMS tests that we
>   run in our CI.
> * I added some AMD maintainers to amdgpu tests.
>
> If you want to try it in your local repository, you will need the
> get_maintainers script from the Linux kernel, and you can use this
> command:
>
>  perl /PATH/TO/get_maintainer.pl --no-tree --separator , --nokeywords --nogit --nogit-fallback --norolestats -f <TARGET_TEST>
>
> Anyway, this is just an idea that I want to discuss with the community.
> What do you think about having a MAINTAINERs file? Do you want to add
> your name as a reviewer to some specific test if you like the idea? Any
> other comments or ideas?
>
> Cc: Arkadiusz Hiler <arek@hiler.eu>
> Cc: Petri Latvala <petri.latvala@intel.com>
> Cc: Mark Yacoub <markyacoub@google.com>
> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
> Cc: Melissa Wen <mwen@igalia.com>
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
> Cc: Wayne Lin <wayne.lin@amd.com>
> Cc: Nicholas Choi <nicholas.choi@amd.com>
> Cc: Martin Peres <martin.peres@mupuf.org>
> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
> Cc: Solomon Chiu <solomon.chiu@amd.com>
>
> Best Regards,
> Siqueira
>
> Rodrigo Siqueira (1):
>   MAINTAINERS: Introduce MAINTAINERS file
>
>  MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 201 insertions(+), 2 deletions(-)
>
> --
> 2.25.1
>

[igt-dev] ✓ Fi.CI.BAT: success for Introduce MAINTAINERS file to IGT

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 7834 bytes --]

== Series Details ==

Series: Introduce MAINTAINERS file to IGT
URL   : https://patchwork.freedesktop.org/series/99534/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11162 -> IGTPW_6588
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/index.html

Participating hosts (47 -> 44)
------------------------------

  Additional (1): fi-pnv-d510 
  Missing    (4): fi-bsw-cyan shard-rkl shard-dg1 shard-tglu 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_6588:

### IGT changes ###

#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@gt_pm:
    - {fi-tgl-dsi}:       [DMESG-FAIL][1] ([i915#1759]) -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/fi-tgl-dsi/igt@i915_selftest@live@gt_pm.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-tgl-dsi/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@workarounds:
    - {bat-adlp-6}:       [PASS][3] -> [DMESG-WARN][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/bat-adlp-6/igt@i915_selftest@live@workarounds.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/bat-adlp-6/igt@i915_selftest@live@workarounds.html

  
Known issues
------------

  Here are the changes found in IGTPW_6588 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@semaphore:
    - fi-hsw-4770:        NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#109315]) +17 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-hsw-4770/igt@amdgpu/amd_basic@semaphore.html

  * igt@gem_huc_copy@huc-copy:
    - fi-skl-6600u:       NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@gem_huc_copy@huc-copy.html
    - fi-pnv-d510:        NOTRUN -> [SKIP][7] ([fdo#109271]) +57 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-pnv-d510/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
    - fi-skl-6600u:       NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@gem_lmem_swapping@verify-random.html

  * igt@i915_selftest@live:
    - fi-skl-6600u:       NOTRUN -> [INCOMPLETE][9] ([i915#4794])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@i915_selftest@live.html

  * igt@i915_selftest@live@workarounds:
    - bat-adlp-4:         [PASS][10] -> [DMESG-FAIL][11] ([i915#5020])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/bat-adlp-4/igt@i915_selftest@live@workarounds.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/bat-adlp-4/igt@i915_selftest@live@workarounds.html

  * igt@kms_chamelium@vga-edid-read:
    - fi-skl-6600u:       NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@kms_chamelium@vga-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-skl-6600u:       NOTRUN -> [SKIP][13] ([fdo#109271]) +3 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-cml-u2:          [PASS][14] -> [DMESG-WARN][15] ([i915#4269])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
    - fi-skl-6600u:       NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html

  
#### Possible fixes ####

  * igt@gem_flink_basic@bad-flink:
    - fi-skl-6600u:       [FAIL][17] ([i915#4547]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html

  * igt@i915_module_load@reload:
    - {fi-tgl-dsi}:       [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/fi-tgl-dsi/igt@i915_module_load@reload.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-tgl-dsi/igt@i915_module_load@reload.html

  * igt@i915_selftest@live@hangcheck:
    - fi-hsw-4770:        [INCOMPLETE][21] ([i915#3303]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
    - fi-cfl-8109u:       [DMESG-WARN][23] ([i915#295]) -> [PASS][24] +11 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/fi-cfl-8109u/igt@kms_pipe_crc_basic@read-crc-pipe-b.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-cfl-8109u/igt@kms_pipe_crc_basic@read-crc-pipe-b.html

  
#### Warnings ####

  * igt@runner@aborted:
    - fi-skl-6600u:       [FAIL][25] ([i915#4312]) -> [FAIL][26] ([i915#1436] / [i915#2722] / [i915#4312])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/fi-skl-6600u/igt@runner@aborted.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/fi-skl-6600u/igt@runner@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4794]: https://gitlab.freedesktop.org/drm/intel/issues/4794
  [i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
  [i915#5020]: https://gitlab.freedesktop.org/drm/intel/issues/5020
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_6337 -> IGTPW_6588

  CI-20190529: 20190529
  CI_DRM_11162: 283ae0e39a86d12ed5351314f1a6abcb2aba5c79 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_6588: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/index.html
  IGT_6337: 7c9c034619ef9dbfbfe041fbf3973a1cf1ac7a22 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/index.html

[-- Attachment #2: Type: text/html, Size: 9183 bytes --]

[igt-dev] ✗ Fi.CI.IGT: failure for Introduce MAINTAINERS file to IGT

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 30250 bytes --]

== Series Details ==

Series: Introduce MAINTAINERS file to IGT
URL   : https://patchwork.freedesktop.org/series/99534/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11162_full -> IGTPW_6588_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_6588_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_6588_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/index.html

Participating hosts (12 -> 8)
------------------------------

  Missing    (4): pig-skl-6260u pig-kbl-iris shard-rkl pig-glk-j5005 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_6588_full:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_flink_race@flink_close:
    - shard-snb:          [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-snb2/igt@gem_flink_race@flink_close.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-snb4/igt@gem_flink_race@flink_close.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * {igt@kms_scaling_modes@scaling-mode-full}:
    - {shard-tglu}:       NOTRUN -> [SKIP][3] +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglu-2/igt@kms_scaling_modes@scaling-mode-full.html

  
Known issues
------------

  Here are the changes found in IGTPW_6588_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_persistence@legacy-engines-hang:
    - shard-snb:          NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-snb2/igt@gem_ctx_persistence@legacy-engines-hang.html

  * igt@gem_eio@kms:
    - shard-tglb:         [PASS][5] -> [FAIL][6] ([i915#232])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-tglb6/igt@gem_eio@kms.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@gem_eio@kms.html

  * igt@gem_eio@unwedge-stress:
    - shard-tglb:         NOTRUN -> [TIMEOUT][7] ([i915#3063] / [i915#3648])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb7/igt@gem_eio@unwedge-stress.html
    - shard-snb:          NOTRUN -> [FAIL][8] ([i915#3354])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-snb4/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-keep-in-fence:
    - shard-iclb:         NOTRUN -> [SKIP][9] ([i915#4525])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb5/igt@gem_exec_balancer@parallel-keep-in-fence.html

  * igt@gem_exec_endless@dispatch@vcs1:
    - shard-tglb:         NOTRUN -> [INCOMPLETE][10] ([i915#3778])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb1/igt@gem_exec_endless@dispatch@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-tglb:         [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-tglb8/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
    - shard-iclb:         [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb2/igt@gem_exec_fair@basic-pace-solo@rcs0.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb5/igt@gem_exec_fair@basic-pace-solo@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
    - shard-glk:          [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-glk2/igt@gem_exec_fair@basic-pace@vcs0.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk3/igt@gem_exec_fair@basic-pace@vcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
    - shard-apl:          NOTRUN -> [DMESG-WARN][17] ([i915#180])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl8/igt@gem_exec_suspend@basic-s3@smem.html

  * igt@gem_huc_copy@huc-copy:
    - shard-tglb:         NOTRUN -> [SKIP][18] ([i915#2190])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb7/igt@gem_huc_copy@huc-copy.html
    - shard-apl:          NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl6/igt@gem_huc_copy@huc-copy.html
    - shard-glk:          NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk2/igt@gem_huc_copy@huc-copy.html
    - shard-iclb:         NOTRUN -> [SKIP][21] ([i915#2190])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb7/igt@gem_huc_copy@huc-copy.html
    - shard-kbl:          NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#2190])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl3/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@parallel-multi:
    - shard-kbl:          NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#4613]) +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl1/igt@gem_lmem_swapping@parallel-multi.html

  * igt@gem_pwrite@basic-exhaustion:
    - shard-kbl:          NOTRUN -> [WARN][24] ([i915#2658])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl1/igt@gem_pwrite@basic-exhaustion.html

  * igt@gem_pxp@verify-pxp-key-change-after-suspend-resume:
    - shard-tglb:         NOTRUN -> [SKIP][25] ([i915#4270]) +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@gem_pxp@verify-pxp-key-change-after-suspend-resume.html

  * igt@gem_pxp@verify-pxp-stale-buf-execution:
    - shard-iclb:         NOTRUN -> [SKIP][26] ([i915#4270]) +1 similar issue
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@gem_pxp@verify-pxp-stale-buf-execution.html

  * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
    - shard-kbl:          NOTRUN -> [SKIP][27] ([fdo#109271]) +232 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl4/igt@gem_render_copy@x-tiled-to-vebox-yf-tiled.html
    - shard-iclb:         NOTRUN -> [SKIP][28] ([i915#768]) +2 similar issues
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@gem_render_copy@x-tiled-to-vebox-yf-tiled.html

  * igt@gem_softpin@allocator-evict-all-engines:
    - shard-glk:          [PASS][29] -> [FAIL][30] ([i915#4171])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-glk8/igt@gem_softpin@allocator-evict-all-engines.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk3/igt@gem_softpin@allocator-evict-all-engines.html

  * igt@gem_userptr_blits@create-destroy-unsync:
    - shard-tglb:         NOTRUN -> [SKIP][31] ([i915#3297]) +1 similar issue
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb1/igt@gem_userptr_blits@create-destroy-unsync.html
    - shard-iclb:         NOTRUN -> [SKIP][32] ([i915#3297]) +1 similar issue
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb1/igt@gem_userptr_blits@create-destroy-unsync.html

  * igt@gen7_exec_parse@batch-without-end:
    - shard-iclb:         NOTRUN -> [SKIP][33] ([fdo#109289]) +2 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb4/igt@gen7_exec_parse@batch-without-end.html
    - shard-tglb:         NOTRUN -> [SKIP][34] ([fdo#109289]) +2 similar issues
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb6/igt@gen7_exec_parse@batch-without-end.html

  * igt@gen9_exec_parse@bb-start-cmd:
    - shard-tglb:         NOTRUN -> [SKIP][35] ([i915#2527] / [i915#2856])
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb3/igt@gen9_exec_parse@bb-start-cmd.html
    - shard-iclb:         NOTRUN -> [SKIP][36] ([i915#2856])
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@gen9_exec_parse@bb-start-cmd.html

  * igt@i915_pm_dc@dc9-dpms:
    - shard-tglb:         NOTRUN -> [SKIP][37] ([i915#4281])
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb6/igt@i915_pm_dc@dc9-dpms.html

  * igt@i915_pm_rpm@modeset-pc8-residency-stress:
    - shard-apl:          NOTRUN -> [SKIP][38] ([fdo#109271]) +55 similar issues
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl1/igt@i915_pm_rpm@modeset-pc8-residency-stress.html
    - shard-tglb:         NOTRUN -> [SKIP][39] ([fdo#109506] / [i915#2411])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@i915_pm_rpm@modeset-pc8-residency-stress.html
    - shard-iclb:         NOTRUN -> [SKIP][40] ([fdo#109293] / [fdo#109506])
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb6/igt@i915_pm_rpm@modeset-pc8-residency-stress.html

  * igt@i915_selftest@live@gt_lrc:
    - shard-iclb:         [PASS][41] -> [DMESG-WARN][42] ([i915#2867]) +5 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb7/igt@i915_selftest@live@gt_lrc.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb6/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_suspend@debugfs-reader:
    - shard-kbl:          NOTRUN -> [DMESG-WARN][43] ([i915#180]) +1 similar issue
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl1/igt@i915_suspend@debugfs-reader.html

  * igt@kms_big_fb@linear-16bpp-rotate-90:
    - shard-iclb:         NOTRUN -> [SKIP][44] ([fdo#110725] / [fdo#111614])
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb6/igt@kms_big_fb@linear-16bpp-rotate-90.html
    - shard-tglb:         NOTRUN -> [SKIP][45] ([fdo#111614])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb3/igt@kms_big_fb@linear-16bpp-rotate-90.html

  * igt@kms_big_fb@linear-64bpp-rotate-180:
    - shard-glk:          [PASS][46] -> [FAIL][47] ([i915#1888])
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-glk7/igt@kms_big_fb@linear-64bpp-rotate-180.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk2/igt@kms_big_fb@linear-64bpp-rotate-180.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
    - shard-apl:          NOTRUN -> [SKIP][48] ([fdo#109271] / [i915#3777])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl4/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
    - shard-glk:          NOTRUN -> [SKIP][49] ([fdo#109271] / [i915#3777])
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk6/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_big_fb@yf-tiled-64bpp-rotate-0:
    - shard-tglb:         NOTRUN -> [SKIP][50] ([fdo#111615]) +3 similar issues
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb7/igt@kms_big_fb@yf-tiled-64bpp-rotate-0.html
    - shard-iclb:         NOTRUN -> [SKIP][51] ([fdo#110723]) +1 similar issue
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb7/igt@kms_big_fb@yf-tiled-64bpp-rotate-0.html

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][52] ([i915#3689] / [i915#3886]) +1 similar issue
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb6/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
    - shard-kbl:          NOTRUN -> [SKIP][53] ([fdo#109271] / [i915#3886]) +8 similar issues
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl1/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs:
    - shard-iclb:         NOTRUN -> [SKIP][54] ([fdo#109278] / [i915#3886]) +2 similar issues
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb3/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html
    - shard-glk:          NOTRUN -> [SKIP][55] ([fdo#109271] / [i915#3886]) +1 similar issue
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk8/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html
    - shard-apl:          NOTRUN -> [SKIP][56] ([fdo#109271] / [i915#3886]) +1 similar issue
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl8/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][57] ([i915#3689]) +1 similar issue
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb5/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_ccs.html

  * igt@kms_ccs@pipe-d-missing-ccs-buffer-yf_tiled_ccs:
    - shard-tglb:         NOTRUN -> [SKIP][58] ([fdo#111615] / [i915#3689]) +2 similar issues
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@kms_ccs@pipe-d-missing-ccs-buffer-yf_tiled_ccs.html

  * igt@kms_chamelium@hdmi-hpd-after-suspend:
    - shard-iclb:         NOTRUN -> [SKIP][59] ([fdo#109284] / [fdo#111827]) +5 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb1/igt@kms_chamelium@hdmi-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-storm:
    - shard-kbl:          NOTRUN -> [SKIP][60] ([fdo#109271] / [fdo#111827]) +20 similar issues
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl1/igt@kms_chamelium@hdmi-hpd-storm.html

  * igt@kms_chamelium@vga-frame-dump:
    - shard-tglb:         NOTRUN -> [SKIP][61] ([fdo#109284] / [fdo#111827]) +5 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb5/igt@kms_chamelium@vga-frame-dump.html

  * igt@kms_color@pipe-d-degamma:
    - shard-iclb:         NOTRUN -> [SKIP][62] ([fdo#109278] / [i915#1149])
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@kms_color@pipe-d-degamma.html

  * igt@kms_color_chamelium@pipe-a-ctm-negative:
    - shard-snb:          NOTRUN -> [SKIP][63] ([fdo#109271] / [fdo#111827]) +7 similar issues
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-snb4/igt@kms_color_chamelium@pipe-a-ctm-negative.html

  * igt@kms_color_chamelium@pipe-b-ctm-limited-range:
    - shard-glk:          NOTRUN -> [SKIP][64] ([fdo#109271] / [fdo#111827]) +5 similar issues
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk2/igt@kms_color_chamelium@pipe-b-ctm-limited-range.html
    - shard-apl:          NOTRUN -> [SKIP][65] ([fdo#109271] / [fdo#111827]) +5 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl6/igt@kms_color_chamelium@pipe-b-ctm-limited-range.html

  * igt@kms_content_protection@legacy:
    - shard-kbl:          NOTRUN -> [TIMEOUT][66] ([i915#1319])
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl7/igt@kms_content_protection@legacy.html

  * igt@kms_cursor_crc@pipe-a-cursor-32x32-sliding:
    - shard-tglb:         NOTRUN -> [SKIP][67] ([i915#3319]) +1 similar issue
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb5/igt@kms_cursor_crc@pipe-a-cursor-32x32-sliding.html

  * igt@kms_cursor_crc@pipe-a-cursor-max-size-rapid-movement:
    - shard-tglb:         NOTRUN -> [SKIP][68] ([i915#3359]) +4 similar issues
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@kms_cursor_crc@pipe-a-cursor-max-size-rapid-movement.html

  * igt@kms_cursor_crc@pipe-c-cursor-512x170-rapid-movement:
    - shard-snb:          NOTRUN -> [SKIP][69] ([fdo#109271]) +125 similar issues
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-snb6/igt@kms_cursor_crc@pipe-c-cursor-512x170-rapid-movement.html

  * igt@kms_cursor_crc@pipe-d-cursor-512x512-rapid-movement:
    - shard-tglb:         NOTRUN -> [SKIP][70] ([fdo#109279] / [i915#3359]) +1 similar issue
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb3/igt@kms_cursor_crc@pipe-d-cursor-512x512-rapid-movement.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
    - shard-glk:          [PASS][71] -> [FAIL][72] ([i915#72])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-glk8/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk7/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
    - shard-iclb:         NOTRUN -> [SKIP][73] ([fdo#109274] / [fdo#109278]) +1 similar issue
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb7/igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic.html

  * igt@kms_flip@2x-flip-vs-dpms:
    - shard-iclb:         NOTRUN -> [SKIP][74] ([fdo#109274]) +3 similar issues
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb6/igt@kms_flip@2x-flip-vs-dpms.html

  * igt@kms_flip@2x-plain-flip-interruptible:
    - shard-tglb:         NOTRUN -> [SKIP][75] ([fdo#109274] / [fdo#111825]) +6 similar issues
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb6/igt@kms_flip@2x-plain-flip-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible@b-dp1:
    - shard-apl:          [PASS][76] -> [DMESG-WARN][77] ([i915#180])
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-apl8/igt@kms_flip@flip-vs-suspend-interruptible@b-dp1.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@b-dp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling:
    - shard-glk:          [PASS][78] -> [FAIL][79] ([i915#4911])
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-glk1/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscaling:
    - shard-iclb:         NOTRUN -> [SKIP][80] ([i915#2587])
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb6/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscaling.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt:
    - shard-iclb:         NOTRUN -> [SKIP][81] ([fdo#109280]) +11 similar issues
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-onoff:
    - shard-tglb:         NOTRUN -> [SKIP][82] ([fdo#109280] / [fdo#111825]) +10 similar issues
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-onoff.html

  * igt@kms_frontbuffer_tracking@fbcpsr-suspend:
    - shard-glk:          NOTRUN -> [SKIP][83] ([fdo#109271]) +53 similar issues
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk8/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html

  * igt@kms_invalid_mode@clock-too-high:
    - shard-tglb:         NOTRUN -> [SKIP][84] ([i915#4278])
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb6/igt@kms_invalid_mode@clock-too-high.html
    - shard-iclb:         NOTRUN -> [SKIP][85] ([i915#4278])
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb4/igt@kms_invalid_mode@clock-too-high.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence:
    - shard-kbl:          NOTRUN -> [SKIP][86] ([fdo#109271] / [i915#533])
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl4/igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-kbl:          [PASS][87] -> [DMESG-WARN][88] ([i915#180]) +1 similar issue
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-kbl1/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
    - shard-kbl:          NOTRUN -> [FAIL][89] ([fdo#108145] / [i915#265]) +4 similar issues
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl6/igt@kms_plane_alpha_blend@pipe-c-alpha-7efc.html

  * igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max:
    - shard-iclb:         NOTRUN -> [SKIP][90] ([fdo#109278]) +17 similar issues
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max.html

  * igt@kms_plane_lowres@pipe-c-tiling-none:
    - shard-iclb:         NOTRUN -> [SKIP][91] ([i915#3536]) +1 similar issue
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb3/igt@kms_plane_lowres@pipe-c-tiling-none.html

  * igt@kms_plane_lowres@pipe-d-tiling-y:
    - shard-tglb:         NOTRUN -> [SKIP][92] ([i915#3536]) +3 similar issues
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb7/igt@kms_plane_lowres@pipe-d-tiling-y.html

  * igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
    - shard-apl:          NOTRUN -> [SKIP][93] ([fdo#109271] / [i915#2733])
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl7/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
    - shard-kbl:          NOTRUN -> [SKIP][94] ([fdo#109271] / [i915#2733])
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl7/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
    - shard-glk:          NOTRUN -> [SKIP][95] ([fdo#109271] / [i915#2733])
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk7/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html

  * igt@kms_psr2_su@frontbuffer-xrgb8888:
    - shard-tglb:         NOTRUN -> [SKIP][96] ([i915#1911])
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@kms_psr2_su@frontbuffer-xrgb8888.html
    - shard-glk:          NOTRUN -> [SKIP][97] ([fdo#109271] / [i915#658])
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk7/igt@kms_psr2_su@frontbuffer-xrgb8888.html
    - shard-apl:          NOTRUN -> [SKIP][98] ([fdo#109271] / [i915#658])
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl1/igt@kms_psr2_su@frontbuffer-xrgb8888.html
    - shard-iclb:         NOTRUN -> [SKIP][99] ([fdo#109642] / [fdo#111068] / [i915#658])
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb6/igt@kms_psr2_su@frontbuffer-xrgb8888.html

  * igt@kms_psr2_su@page_flip-xrgb8888:
    - shard-kbl:          NOTRUN -> [SKIP][100] ([fdo#109271] / [i915#658]) +1 similar issue
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl7/igt@kms_psr2_su@page_flip-xrgb8888.html

  * igt@kms_psr@psr2_cursor_plane_move:
    - shard-iclb:         [PASS][101] -> [SKIP][102] ([fdo#109441])
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb3/igt@kms_psr@psr2_cursor_plane_move.html

  * igt@kms_psr@psr2_sprite_blt:
    - shard-tglb:         NOTRUN -> [FAIL][103] ([i915#132] / [i915#3467]) +1 similar issue
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb7/igt@kms_psr@psr2_sprite_blt.html

  * igt@kms_psr@psr2_suspend:
    - shard-iclb:         NOTRUN -> [SKIP][104] ([fdo#109441]) +1 similar issue
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb7/igt@kms_psr@psr2_suspend.html

  * igt@kms_writeback@writeback-check-output:
    - shard-kbl:          NOTRUN -> [SKIP][105] ([fdo#109271] / [i915#2437])
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl4/igt@kms_writeback@writeback-check-output.html

  * igt@nouveau_crc@pipe-a-source-outp-inactive:
    - shard-iclb:         NOTRUN -> [SKIP][106] ([i915#2530])
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@nouveau_crc@pipe-a-source-outp-inactive.html
    - shard-tglb:         NOTRUN -> [SKIP][107] ([i915#2530])
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb8/igt@nouveau_crc@pipe-a-source-outp-inactive.html

  * igt@perf@polling-parameterized:
    - shard-iclb:         [PASS][108] -> [FAIL][109] ([i915#1542])
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb8/igt@perf@polling-parameterized.html
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb1/igt@perf@polling-parameterized.html

  * igt@prime_nv_pcopy@test_semaphore:
    - shard-iclb:         NOTRUN -> [SKIP][110] ([fdo#109291]) +1 similar issue
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb2/igt@prime_nv_pcopy@test_semaphore.html
    - shard-tglb:         NOTRUN -> [SKIP][111] ([fdo#109291])
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb1/igt@prime_nv_pcopy@test_semaphore.html

  * igt@sysfs_clients@fair-3:
    - shard-kbl:          NOTRUN -> [SKIP][112] ([fdo#109271] / [i915#2994]) +3 similar issues
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl7/igt@sysfs_clients@fair-3.html
    - shard-tglb:         NOTRUN -> [SKIP][113] ([i915#2994]) +1 similar issue
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-tglb2/igt@sysfs_clients@fair-3.html

  * igt@sysfs_clients@split-10:
    - shard-iclb:         NOTRUN -> [SKIP][114] ([i915#2994]) +1 similar issue
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb1/igt@sysfs_clients@split-10.html
    - shard-glk:          NOTRUN -> [SKIP][115] ([fdo#109271] / [i915#2994]) +1 similar issue
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk6/igt@sysfs_clients@split-10.html
    - shard-apl:          NOTRUN -> [SKIP][116] ([fdo#109271] / [i915#2994]) +1 similar issue
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-apl4/igt@sysfs_clients@split-10.html

  
#### Possible fixes ####

  * igt@gem_exec_balancer@parallel-out-fence:
    - shard-iclb:         [SKIP][117] ([i915#4525]) -> [PASS][118]
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb8/igt@gem_exec_balancer@parallel-out-fence.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb2/igt@gem_exec_balancer@parallel-out-fence.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
    - shard-kbl:          [FAIL][119] ([i915#2842]) -> [PASS][120]
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-kbl6/igt@gem_exec_fair@basic-pace-solo@rcs0.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl1/igt@gem_exec_fair@basic-pace-solo@rcs0.html

  * igt@gem_exec_whisper@basic-contexts-all:
    - shard-iclb:         [INCOMPLETE][121] -> [PASS][122]
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb2/igt@gem_exec_whisper@basic-contexts-all.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@gem_exec_whisper@basic-contexts-all.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
    - shard-glk:          [DMESG-WARN][123] ([i915#118]) -> [PASS][124] +1 similar issue
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-glk8/igt@gem_exec_whisper@basic-queues-forked-all.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk9/igt@gem_exec_whisper@basic-queues-forked-all.html

  * igt@kms_async_flips@alternate-sync-async-flip:
    - shard-glk:          [FAIL][125] ([i915#2521]) -> [PASS][126]
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-glk5/igt@kms_async_flips@alternate-sync-async-flip.html
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-glk8/igt@kms_async_flips@alternate-sync-async-flip.html

  * igt@kms_cursor_legacy@flip-vs-cursor-varying-size:
    - shard-iclb:         [FAIL][127] ([i915#2346]) -> [PASS][128] +1 similar issue
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb8/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-kbl:          [INCOMPLETE][129] ([i915#180] / [i915#636]) -> [PASS][130]
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
    - shard-kbl:          [DMESG-WARN][131] ([i915#180]) -> [PASS][132] +9 similar issues
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-kbl3/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [SKIP][133] ([fdo#109441]) -> [PASS][134] +1 similar issue
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11162/shard-iclb4/igt@kms_psr@psr2_cursor_render.html
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/shard-iclb2/igt@kms_psr@psr2_cursor_render.html

  
#### Warnings ####

  * igt@gem_exec_balancer@parallel-ordering:
    - shard-iclb:

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6588/index.html

[-- Attachment #2: Type: text/html, Size: 33719 bytes --]

Re: [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[Mark Yacoub]

On Mon, Jan 31, 2022 at 10:18 AM Sean Paul <seanpaul@chromium.org> wrote:
>
> On Mon, Jan 31, 2022 at 9:29 AM Rodrigo Siqueira
> <Rodrigo.Siqueira@amd.com> wrote:
> >
> > Hi,
> >
> > IGT is becoming more generic, and multiple vendors are adopting it. For
> > example, AMD fully upstream all of its internal changes last year, and
> > now we are relying on IGT from the upstream. Additionally, thanks to the
> > ChromeOS project, we have other vendors working on the KMS tests as
> > well. At this point, I believe that we need some mechanism to better
> > contact developers that care about some specific tests or even provide an
> > easy way for other people to find the right stakeholder for dealing with
> > some particular issue.
> >
>
> Hi Siqueira,
> Do you have a sense for how much of this is necessary once igt
> transitions to gitlab merge requests (or what it looks like in that
> new reality)? IIRC the reason igt is not using MR's is because of some
> CI infrastructure only talking mailing list, I was under the
> impression that was changing and MR's were the way forward.
>
> Sean
>
I still see value for a maitainer list, not just for code reviews.
I find it as a useful tool for Point of Contact when a test fails.
If we suddenly see a test failing on a certain device, we can look up
who would knows best about it. Or even if there are questions about a
specific thing in a test on a certain SoC.

@Petri, do we know if MRs are coming soon?
> > Imho Linux Kernel already has a good solution codified in the
> > MAINTAINERS and get_maintainers files. One of the best things about this
> > approach was adding reviewers and maintainers (and other options) to the
> > specific part of the code and using the get_maintainers tool to extract
> > the right people to be part of the series. With this idea in mind, I
> > created this RFC that introduces the MAINTAINERS file in IGT, and I have
> > already added some entries to this file. My approach was:
> >
> > * Petri and Hiler are the maintainers, and for this reason, their
> >   contact will be displayed for every patch.
> > * I add Mark Yacoub as a reviewer for every KMS test.
> > * I added some AMD folks as reviewers in some specific KMS tests that we
> >   run in our CI.
> > * I added some AMD maintainers to amdgpu tests.
> >
> > If you want to try it in your local repository, you will need the
> > get_maintainers script from the Linux kernel, and you can use this
> > command:
> >
> >  perl /PATH/TO/get_maintainer.pl --no-tree --separator , --nokeywords --nogit --nogit-fallback --norolestats -f <TARGET_TEST>
> >
> > Anyway, this is just an idea that I want to discuss with the community.
> > What do you think about having a MAINTAINERs file? Do you want to add
> > your name as a reviewer to some specific test if you like the idea? Any
> > other comments or ideas?
> >
> > Cc: Arkadiusz Hiler <arek@hiler.eu>
> > Cc: Petri Latvala <petri.latvala@intel.com>
> > Cc: Mark Yacoub <markyacoub@google.com>
> > Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
> > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
> > Cc: Melissa Wen <mwen@igalia.com>
> > Cc: Sean Paul <seanpaul@chromium.org>
> > Cc: Harry Wentland <harry.wentland@amd.com>
> > Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
> > Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
> > Cc: Wayne Lin <wayne.lin@amd.com>
> > Cc: Nicholas Choi <nicholas.choi@amd.com>
> > Cc: Martin Peres <martin.peres@mupuf.org>
> > Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
> > Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> > Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
> > Cc: Solomon Chiu <solomon.chiu@amd.com>
> >
> > Best Regards,
> > Siqueira
> >
> > Rodrigo Siqueira (1):
> >   MAINTAINERS: Introduce MAINTAINERS file
> >
> >  MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 201 insertions(+), 2 deletions(-)
> >
> > --
> > 2.25.1
> >

Re: [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[Harry Wentland]

On 2022-01-31 10:11, Sean Paul wrote:
> On Mon, Jan 31, 2022 at 9:29 AM Rodrigo Siqueira
> <Rodrigo.Siqueira@amd.com> wrote:
>>
>> Hi,
>>
>> IGT is becoming more generic, and multiple vendors are adopting it. For
>> example, AMD fully upstream all of its internal changes last year, and
>> now we are relying on IGT from the upstream. Additionally, thanks to the
>> ChromeOS project, we have other vendors working on the KMS tests as
>> well. At this point, I believe that we need some mechanism to better
>> contact developers that care about some specific tests or even provide an
>> easy way for other people to find the right stakeholder for dealing with
>> some particular issue.
>>
> 
> Hi Siqueira,
> Do you have a sense for how much of this is necessary once igt
> transitions to gitlab merge requests (or what it looks like in that
> new reality)? IIRC the reason igt is not using MR's is because of some
> CI infrastructure only talking mailing list, I was under the
> impression that was changing and MR's were the way forward.
> 

Do you (or anyone else) have a rough timeframe on when that's likely
to happen?

In either case, this approach to formalize who the experts for different
IGT tests are would be helpful regardless.

FWIW, this patchset is
Acked-by: Harry Wentland <harry.wentland@amd.com>

Harry

> Sean
> 
>> Imho Linux Kernel already has a good solution codified in the
>> MAINTAINERS and get_maintainers files. One of the best things about this
>> approach was adding reviewers and maintainers (and other options) to the
>> specific part of the code and using the get_maintainers tool to extract
>> the right people to be part of the series. With this idea in mind, I
>> created this RFC that introduces the MAINTAINERS file in IGT, and I have
>> already added some entries to this file. My approach was:
>>
>> * Petri and Hiler are the maintainers, and for this reason, their
>>   contact will be displayed for every patch.
>> * I add Mark Yacoub as a reviewer for every KMS test.
>> * I added some AMD folks as reviewers in some specific KMS tests that we
>>   run in our CI.
>> * I added some AMD maintainers to amdgpu tests.
>>
>> If you want to try it in your local repository, you will need the
>> get_maintainers script from the Linux kernel, and you can use this
>> command:
>>
>>  perl /PATH/TO/get_maintainer.pl --no-tree --separator , --nokeywords --nogit --nogit-fallback --norolestats -f <TARGET_TEST>
>>
>> Anyway, this is just an idea that I want to discuss with the community.
>> What do you think about having a MAINTAINERs file? Do you want to add
>> your name as a reviewer to some specific test if you like the idea? Any
>> other comments or ideas?
>>
>> Cc: Arkadiusz Hiler <arek@hiler.eu>
>> Cc: Petri Latvala <petri.latvala@intel.com>
>> Cc: Mark Yacoub <markyacoub@google.com>
>> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
>> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
>> Cc: Melissa Wen <mwen@igalia.com>
>> Cc: Sean Paul <seanpaul@chromium.org>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
>> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
>> Cc: Wayne Lin <wayne.lin@amd.com>
>> Cc: Nicholas Choi <nicholas.choi@amd.com>
>> Cc: Martin Peres <martin.peres@mupuf.org>
>> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
>> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
>> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
>> Cc: Solomon Chiu <solomon.chiu@amd.com>
>>
>> Best Regards,
>> Siqueira
>>
>> Rodrigo Siqueira (1):
>>   MAINTAINERS: Introduce MAINTAINERS file
>>
>>  MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 201 insertions(+), 2 deletions(-)
>>
>> --
>> 2.25.1
>>

Re: [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[Petri Latvala]

On Mon, Jan 31, 2022 at 01:19:20PM -0500, Mark Yacoub wrote:
> On Mon, Jan 31, 2022 at 10:18 AM Sean Paul <seanpaul@chromium.org> wrote:
> >
> > On Mon, Jan 31, 2022 at 9:29 AM Rodrigo Siqueira
> > <Rodrigo.Siqueira@amd.com> wrote:
> > >
> > > Hi,
> > >
> > > IGT is becoming more generic, and multiple vendors are adopting it. For
> > > example, AMD fully upstream all of its internal changes last year, and
> > > now we are relying on IGT from the upstream. Additionally, thanks to the
> > > ChromeOS project, we have other vendors working on the KMS tests as
> > > well. At this point, I believe that we need some mechanism to better
> > > contact developers that care about some specific tests or even provide an
> > > easy way for other people to find the right stakeholder for dealing with
> > > some particular issue.
> > >
> >
> > Hi Siqueira,
> > Do you have a sense for how much of this is necessary once igt
> > transitions to gitlab merge requests (or what it looks like in that
> > new reality)? IIRC the reason igt is not using MR's is because of some
> > CI infrastructure only talking mailing list, I was under the
> > impression that was changing and MR's were the way forward.
> >
> > Sean
> >
> I still see value for a maitainer list, not just for code reviews.
> I find it as a useful tool for Point of Contact when a test fails.
> If we suddenly see a test failing on a certain device, we can look up
> who would knows best about it. Or even if there are questions about a
> specific thing in a test on a certain SoC.
> 
> @Petri, do we know if MRs are coming soon?

They are coming, but I don't have any timeframes to even
guesstimate. Martin and Arek were working on the patchwork-gitlab
bridge and I don't have recent updates on that effort.

-- 
Petri Latvala


> > > Imho Linux Kernel already has a good solution codified in the
> > > MAINTAINERS and get_maintainers files. One of the best things about this
> > > approach was adding reviewers and maintainers (and other options) to the
> > > specific part of the code and using the get_maintainers tool to extract
> > > the right people to be part of the series. With this idea in mind, I
> > > created this RFC that introduces the MAINTAINERS file in IGT, and I have
> > > already added some entries to this file. My approach was:
> > >
> > > * Petri and Hiler are the maintainers, and for this reason, their
> > >   contact will be displayed for every patch.
> > > * I add Mark Yacoub as a reviewer for every KMS test.
> > > * I added some AMD folks as reviewers in some specific KMS tests that we
> > >   run in our CI.
> > > * I added some AMD maintainers to amdgpu tests.
> > >
> > > If you want to try it in your local repository, you will need the
> > > get_maintainers script from the Linux kernel, and you can use this
> > > command:
> > >
> > >  perl /PATH/TO/get_maintainer.pl --no-tree --separator , --nokeywords --nogit --nogit-fallback --norolestats -f <TARGET_TEST>
> > >
> > > Anyway, this is just an idea that I want to discuss with the community.
> > > What do you think about having a MAINTAINERs file? Do you want to add
> > > your name as a reviewer to some specific test if you like the idea? Any
> > > other comments or ideas?
> > >
> > > Cc: Arkadiusz Hiler <arek@hiler.eu>
> > > Cc: Petri Latvala <petri.latvala@intel.com>
> > > Cc: Mark Yacoub <markyacoub@google.com>
> > > Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
> > > Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
> > > Cc: Melissa Wen <mwen@igalia.com>
> > > Cc: Sean Paul <seanpaul@chromium.org>
> > > Cc: Harry Wentland <harry.wentland@amd.com>
> > > Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
> > > Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
> > > Cc: Wayne Lin <wayne.lin@amd.com>
> > > Cc: Nicholas Choi <nicholas.choi@amd.com>
> > > Cc: Martin Peres <martin.peres@mupuf.org>
> > > Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
> > > Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> > > Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
> > > Cc: Solomon Chiu <solomon.chiu@amd.com>
> > >
> > > Best Regards,
> > > Siqueira
> > >
> > > Rodrigo Siqueira (1):
> > >   MAINTAINERS: Introduce MAINTAINERS file
> > >
> > >  MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> > >  1 file changed, 201 insertions(+), 2 deletions(-)
> > >
> > > --
> > > 2.25.1
> > >

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

[Petri Latvala]

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@hiler.eu>
> Cc: Petri Latvala <petri.latvala@intel.com>
> Cc: Mark Yacoub <markyacoub@google.com>
> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
> Cc: Melissa Wen <mwen@igalia.com>
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
> Cc: Wayne Lin <wayne.lin@amd.com>
> Cc: Nicholas Choi <nicholas.choi@amd.com>
> Cc: Martin Peres <martin.peres@mupuf.org>
> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
> Cc: Solomon Chiu <solomon.chiu@amd.com>
> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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@intel.com>
> -Arkadiusz Hiler <arek@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@domain>
> +	R: Designated *Reviewer*: FullName <address@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@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@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@amd.com>
> +F:	tests/kms_hdr.c
> +
> +KMS Color
> +R:	Stylon Wang <stylon.wang@amd.com>
> +F:	tests/kms_multipipe_modeset.c
> +
> +KMS Content protection
> +R:	Stylon Wang <stylon.wang@amd.com>
> +R:	Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> +F:	tests/kms_content_protection.c
> +
> +KMS Cursor tests
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira@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@amd.com>
> +S:	Maintained
> +F:	tests/kms_vblank.c
> +
> +KMS Vblank tests
> +R:	Aurabindo Pillai <aurabindo.pillai@amd.com>
> +S:	Maintained
> +F:	tests/kms_vblank.c
> +
> +KMS Flip tests
> +R:	Aurabindo Pillai <aurabindo.pillai@amd.com>
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
> +S:	Maintained
> +F:	tests/kms_flip.c
> +F:	tests/kms_flip_event_leak.c
> +
> +KMS plane tests
> +R:	Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
> +S:	Maintained
> +S:	Maintained
> +F:	tests/kms_plane.c
> +F:	tests/kms_plane_scaling.c
> +
> +AMDGPU
> +M:	Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
> +M:	Stylon Wang <stylon.wang@amd.com>
> +M:	Wayne Lin <Wayne.Lin@amd.com>
> +S:	Maintained
> +F:	tests/amdgpu/*
> +
> +AMDGPU AMD Plane
> +M:	Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> +F:	tests/amdgpu/amd_plane.c
> +
> +AMDGPU AMD Color
> +M:	Wayne Lin <Wayne.Lin@amd.com>
> +F:	tests/amdgpu/amd_color.c
> +F:	tests/amdgpu/amd_max_bpc.c
> +
> +AMDGPU AMD content protection
> +M:	Stylon Wang <stylon.wang@amd.com>
> +M:	Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> +F:	tests/amdgpu/amd_assr.c
> +
> +All KMS tests
> +R:	Mark Yacoub <markyacoub@chromium.org>
> +F:	tests/kms_*
> +
> +THE REST
> +M:	Arkadiusz Hiler <arek@hiler.eu>
> +M:	Petri Latvala <petri.latvala@intel.com>
> +L:	Development mailing list for IGT GPU Tools <igt-dev@lists.freedesktop.org>
> +S:	Buried alive in reporters
> +Q:	https://patchwork.freedesktop.org/project/igt/series/?ordering=-last_updated
> +T:	git@gitlab.freedesktop.org:drm/igt-gpu-tools.git
> +F:	*
> +F:	*/
> -- 
> 2.25.1
> 

Re: [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[Melissa Wen]

[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]

On 01/31, Rodrigo Siqueira wrote:
> Hi,
> 
> IGT is becoming more generic, and multiple vendors are adopting it. For
> example, AMD fully upstream all of its internal changes last year, and
> now we are relying on IGT from the upstream. Additionally, thanks to the
> ChromeOS project, we have other vendors working on the KMS tests as
> well. At this point, I believe that we need some mechanism to better
> contact developers that care about some specific tests or even provide an
> easy way for other people to find the right stakeholder for dealing with
> some particular issue.
> 
> Imho Linux Kernel already has a good solution codified in the
> MAINTAINERS and get_maintainers files. One of the best things about this
> approach was adding reviewers and maintainers (and other options) to the
> specific part of the code and using the get_maintainers tool to extract
> the right people to be part of the series. With this idea in mind, I
> created this RFC that introduces the MAINTAINERS file in IGT, and I have
> already added some entries to this file. My approach was:
> 
> * Petri and Hiler are the maintainers, and for this reason, their
>   contact will be displayed for every patch.
> * I add Mark Yacoub as a reviewer for every KMS test.
> * I added some AMD folks as reviewers in some specific KMS tests that we
>   run in our CI.
> * I added some AMD maintainers to amdgpu tests.
> 
> If you want to try it in your local repository, you will need the
> get_maintainers script from the Linux kernel, and you can use this
> command:
> 
>  perl /PATH/TO/get_maintainer.pl --no-tree --separator , --nokeywords --nogit --nogit-fallback --norolestats -f <TARGET_TEST>
> 
> Anyway, this is just an idea that I want to discuss with the community.
> What do you think about having a MAINTAINERs file? Do you want to add
> your name as a reviewer to some specific test if you like the idea? Any
> other comments or ideas?

I agree with the idea of having a way to find the developers interested
in reviewing changes for a specific test. Also I think it can diversify
feedback for generic tests. That said,
Acked-by: Melissa Wen <mwen@igalia.com>

I'm not clear if the `Reviewer` role is just to point developers that
are willing to review patches to a specific set of tests or developers
that also have commit rights. For example, I don't have commit rights
here, but I'm interested in reviewing patches for v3d and KMS CRC too.

> 
> Cc: Arkadiusz Hiler <arek@hiler.eu>
> Cc: Petri Latvala <petri.latvala@intel.com>
> Cc: Mark Yacoub <markyacoub@google.com>
> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
> Cc: Melissa Wen <mwen@igalia.com>
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
> Cc: Wayne Lin <wayne.lin@amd.com>
> Cc: Nicholas Choi <nicholas.choi@amd.com>
> Cc: Martin Peres <martin.peres@mupuf.org>
> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
> Cc: Solomon Chiu <solomon.chiu@amd.com>
> 
> Best Regards,
> Siqueira
> 
> Rodrigo Siqueira (1):
>   MAINTAINERS: Introduce MAINTAINERS file
> 
>  MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 201 insertions(+), 2 deletions(-)
> 
> -- 
> 2.25.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Harry Wentland]

On 2022-02-03 06:03, Petri Latvala wrote:
> 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@hiler.eu>
>> Cc: Petri Latvala <petri.latvala@intel.com>
>> Cc: Mark Yacoub <markyacoub@google.com>
>> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
>> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
>> Cc: Melissa Wen <mwen@igalia.com>
>> Cc: Sean Paul <seanpaul@chromium.org>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
>> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
>> Cc: Wayne Lin <wayne.lin@amd.com>
>> Cc: Nicholas Choi <nicholas.choi@amd.com>
>> Cc: Martin Peres <martin.peres@mupuf.org>
>> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
>> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
>> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
>> Cc: Solomon Chiu <solomon.chiu@amd.com>
>> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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.
> 

I tend to agree with the statement that this has too much useless
complexity and would love if that'd be dropped/cleaned up, though
that could come at a later time (and might be less important if
IGT moves to gitlab MRs).

Harry

> (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...
> 
> 

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

[Rodrigo Siqueira Jordao]

On 2022-02-03 6:03 a.m., Petri Latvala wrote:
> 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@hiler.eu>
>> Cc: Petri Latvala <petri.latvala@intel.com>
>> Cc: Mark Yacoub <markyacoub@google.com>
>> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
>> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
>> Cc: Melissa Wen <mwen@igalia.com>
>> Cc: Sean Paul <seanpaul@chromium.org>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
>> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
>> Cc: Wayne Lin <wayne.lin@amd.com>
>> Cc: Nicholas Choi <nicholas.choi@amd.com>
>> Cc: Martin Peres <martin.peres@mupuf.org>
>> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
>> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
>> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
>> Cc: Solomon Chiu <solomon.chiu@amd.com>
>> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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.

Hi Petri,

Thanks for your feedback. I just copy-paste most parts of this kernel 
MAINTAINERs file since this is just a prototype. I will prepare the 
first version of this patch and submit it again; in this new version, I 
will drop some part of the documentation which does not make sense for IGT.

> (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...

My main concern about sending the get_maintainers patch is the effort 
duplication since this file is actively maintained under the Linux tree, 
and we will need to sync this script manually. How about adding a link 
to this script instead of adding it as part of IGT?

Thanks
Siqueira

> 
Hi Petri,

Re: [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT

[Rodrigo Siqueira Jordao]

On 2022-02-03 7:50 a.m., Melissa Wen wrote:
> On 01/31, Rodrigo Siqueira wrote:
>> Hi,
>>
>> IGT is becoming more generic, and multiple vendors are adopting it. For
>> example, AMD fully upstream all of its internal changes last year, and
>> now we are relying on IGT from the upstream. Additionally, thanks to the
>> ChromeOS project, we have other vendors working on the KMS tests as
>> well. At this point, I believe that we need some mechanism to better
>> contact developers that care about some specific tests or even provide an
>> easy way for other people to find the right stakeholder for dealing with
>> some particular issue.
>>
>> Imho Linux Kernel already has a good solution codified in the
>> MAINTAINERS and get_maintainers files. One of the best things about this
>> approach was adding reviewers and maintainers (and other options) to the
>> specific part of the code and using the get_maintainers tool to extract
>> the right people to be part of the series. With this idea in mind, I
>> created this RFC that introduces the MAINTAINERS file in IGT, and I have
>> already added some entries to this file. My approach was:
>>
>> * Petri and Hiler are the maintainers, and for this reason, their
>>    contact will be displayed for every patch.
>> * I add Mark Yacoub as a reviewer for every KMS test.
>> * I added some AMD folks as reviewers in some specific KMS tests that we
>>    run in our CI.
>> * I added some AMD maintainers to amdgpu tests.
>>
>> If you want to try it in your local repository, you will need the
>> get_maintainers script from the Linux kernel, and you can use this
>> command:
>>
>>   perl /PATH/TO/get_maintainer.pl --no-tree --separator , --nokeywords --nogit --nogit-fallback --norolestats -f <TARGET_TEST>
>>
>> Anyway, this is just an idea that I want to discuss with the community.
>> What do you think about having a MAINTAINERs file? Do you want to add
>> your name as a reviewer to some specific test if you like the idea? Any
>> other comments or ideas?
> 
> I agree with the idea of having a way to find the developers interested
> in reviewing changes for a specific test. Also I think it can diversify
> feedback for generic tests. That said,
> Acked-by: Melissa Wen <mwen@igalia.com>
> 
> I'm not clear if the `Reviewer` role is just to point developers that
> are willing to review patches to a specific set of tests or developers
> that also have commit rights. For example, I don't have commit rights
> here, but I'm interested in reviewing patches for v3d and KMS CRC too.

Hi Melissa,

AFAIK, `reviewer` is just a developer willing to review.

In the new version of this Patch, I will add you as a reviewer for the 
v3d tests and kms crc.

Thanks
Siqueira

>>
>> Cc: Arkadiusz Hiler <arek@hiler.eu>
>> Cc: Petri Latvala <petri.latvala@intel.com>
>> Cc: Mark Yacoub <markyacoub@google.com>
>> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
>> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
>> Cc: Melissa Wen <mwen@igalia.com>
>> Cc: Sean Paul <seanpaul@chromium.org>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
>> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
>> Cc: Wayne Lin <wayne.lin@amd.com>
>> Cc: Nicholas Choi <nicholas.choi@amd.com>
>> Cc: Martin Peres <martin.peres@mupuf.org>
>> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
>> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
>> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
>> Cc: Solomon Chiu <solomon.chiu@amd.com>
>>
>> Best Regards,
>> Siqueira
>>
>> Rodrigo Siqueira (1):
>>    MAINTAINERS: Introduce MAINTAINERS file
>>
>>   MAINTAINERS | 203 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 201 insertions(+), 2 deletions(-)
>>
>> -- 
>> 2.25.1
>>

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

[Jani Nikula]

On Thu, 03 Feb 2022, Rodrigo Siqueira Jordao <rjordrigo@amd.com> wrote:
> On 2022-02-03 6:03 a.m., Petri Latvala wrote:
>> 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@hiler.eu>
>>> Cc: Petri Latvala <petri.latvala@intel.com>
>>> Cc: Mark Yacoub <markyacoub@google.com>
>>> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
>>> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
>>> Cc: Melissa Wen <mwen@igalia.com>
>>> Cc: Sean Paul <seanpaul@chromium.org>
>>> Cc: Harry Wentland <harry.wentland@amd.com>
>>> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
>>> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
>>> Cc: Wayne Lin <wayne.lin@amd.com>
>>> Cc: Nicholas Choi <nicholas.choi@amd.com>
>>> Cc: Martin Peres <martin.peres@mupuf.org>
>>> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
>>> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
>>> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
>>> Cc: Solomon Chiu <solomon.chiu@amd.com>
>>> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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.
>
> Hi Petri,
>
> Thanks for your feedback. I just copy-paste most parts of this kernel 
> MAINTAINERs file since this is just a prototype. I will prepare the 
> first version of this patch and submit it again; in this new version, I 
> will drop some part of the documentation which does not make sense for IGT.

FWIW, if I were to do this, I'd do it in yaml and implement it in
python+strictyaml with a schema. No need to import a monster perl parser
from kernel or implement our own.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

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

[Petri Latvala]

On Mon, Feb 07, 2022 at 02:31:03PM +0200, Jani Nikula wrote:
> On Thu, 03 Feb 2022, Rodrigo Siqueira Jordao <rjordrigo@amd.com> wrote:
> > On 2022-02-03 6:03 a.m., Petri Latvala wrote:
> >> 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@hiler.eu>
> >>> Cc: Petri Latvala <petri.latvala@intel.com>
> >>> Cc: Mark Yacoub <markyacoub@google.com>
> >>> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
> >>> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
> >>> Cc: Melissa Wen <mwen@igalia.com>
> >>> Cc: Sean Paul <seanpaul@chromium.org>
> >>> Cc: Harry Wentland <harry.wentland@amd.com>
> >>> Cc: Sun Peng Li(Leo) <sunpeng.li@amd.com>
> >>> Cc: Chao-kai Wang (Stylon) <stylon.wang@amd.com>
> >>> Cc: Wayne Lin <wayne.lin@amd.com>
> >>> Cc: Nicholas Choi <nicholas.choi@amd.com>
> >>> Cc: Martin Peres <martin.peres@mupuf.org>
> >>> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
> >>> Cc: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
> >>> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo@amd.com>
> >>> Cc: Solomon Chiu <solomon.chiu@amd.com>
> >>> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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.
> >
> > Hi Petri,
> >
> > Thanks for your feedback. I just copy-paste most parts of this kernel 
> > MAINTAINERs file since this is just a prototype. I will prepare the 
> > first version of this patch and submit it again; in this new version, I 
> > will drop some part of the documentation which does not make sense for IGT.
> 
> FWIW, if I were to do this, I'd do it in yaml and implement it in
> python+strictyaml with a schema. No need to import a monster perl parser
> from kernel or implement our own.

I really like this suggestion. The perl script from kernel is
completely overkill for IGT purposes where it would be mostly (or
100%) used to collect Cc fields to patches for people volunteering for
doing review.


-- 
Petri Latvala

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

[Jani Nikula]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Wed, 02 Mar 2022, Petri Latvala <petri.latvala@intel.com> wrote:
> On Mon, Feb 07, 2022 at 02:31:03PM +0200, Jani Nikula wrote:
>> FWIW, if I were to do this, I'd do it in yaml and implement it in
>> python+strictyaml with a schema. No need to import a monster perl parser
>> from kernel or implement our own.
>
> I really like this suggestion. The perl script from kernel is
> completely overkill for IGT purposes where it would be mostly (or
> 100%) used to collect Cc fields to patches for people volunteering for
> doing review.

Last week I hacked a bit on what my suggestion would look like, but
decided I really don't have time for this. Anyway, attached is what I
put together in less than an hour in case anyone wants to pick it up
from here.

You'll need strictyaml and whatthepatch from pip. The latter could
perhaps be replaced with something better but it fit the bill now and it
took only minutes to start using. Using strictyaml with a schema is a
really powerful tool here.

Put the attachments in igt root (they're not even patches, sorry), and
try:

$ ./maintainers.py some-igt.patch

The MAINTAINERS used here is just a conversion from some earlier patch,
don't put too much weight on the content, rather the format.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center


[-- Attachment #2: MAINTAINERS --]
[-- Type: text/plain, Size: 4240 bytes --]

KMS Generic API tests:
 Reviewers:
  - Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
  - Qingqing Zhuo (Lilian) <Qingqing.Zhuo@amd.com@amd.com>
  - Aurabindo Pillai <aurabindo.pillai@amd.com>
 Files:
  - tests/kms_atomic.c
  - tests/kms_atomic_interruptible.c
  - tests/kms_atomic_transition.c
  - tests/kms_properties.c
  - tests/kms_setmode.c
  - tests/kms_concurrent.c
  - tests/kms_prop_blob.c
  - tests/kms_multipipe_modeset.c

KMS CRC API:
 Reviewers:
  - Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
  - Sunpeng Li (Leo) <Sunpeng.Li@amd.com>
  - Dingchen Zhang (David) <Dingchen.Zhang@amd.com>
  - Melissa Wen <mwen@igalia.com>
 Files:
  - tests/kms_cursor_crc.c
  - tests/kms_pipe_crc_basic.c
  - tests/kms_rotation_crc.c

KMS HDR:
 Reviewers:
  - Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>

KMS Color:
 Reviewers:
  - Stylon Wang <stylon.wang@amd.com>
  - Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
  - Sunpeng Li (Leo) <Sunpeng.Li@amd.com>
 Files:
  - tests/kms_color.c

KMS Content protection:
 Reviewers:
  - Dingchen Zhang (David) <Dingchen.Zhang@amd.com>
  - Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
 Files:
  - tests/kms_content_protection.c

KMS Cursor tests:
 Reviewers:
  - Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
  - Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
 Files:
  - tests/kms_cursor_legacy.c
  - tests/kms_cursor_edge_walk.c
  - tests/kms_plane_cursor.c
  - tests/kms_plane_alpha_blend.c

VRR tests:
 Reviewers:
  - Stylon Wang <stylon.wang@amd.com>
  - Wayne Lin <Wayne.Lin@amd.com>
  - Solomon Chiu <Solomon.Chiu@amd.com>
  - Aurabindo Pillai <aurabindo.pillai@amd.com>
  - Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
 Status: Maintained
 Files:
  - tests/kms_vrr.c

KMS Vblank tests:
 Reviewers:
  - Aurabindo Pillai <aurabindo.pillai@amd.com>
  - Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
 Status: Maintained
 Files:
  - tests/kms_vblank.c

KMS Flip tests:
 Reviewers:
  - Aurabindo Pillai <aurabindo.pillai@amd.com>
  - Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
 Status: Maintained
 Files:
  - tests/kms_flip.c
  - tests/kms_flip_event_leak.c

KMS plane tests:
 Reviewers:
  - Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
  - Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
  - Stylon Wang <stylon.wang@amd.com>
 Status: Maintained
 Files:
  - tests/kms_plane.c
  - tests/kms_plane_scaling.c

KMS Bandwidth:
 Reviewers:
  - Aurabindo Pillai <aurabindo.pillai@amd.com>
 Files:
  - tests/kms_bw.c

AMDGPU:
 Maintainers:
  - Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
  - Stylon Wang <stylon.wang@amd.com>
  - Wayne Lin <Wayne.Lin@amd.com>
 Status: Maintained
 Files:
  - tests/amdgpu/*

AMDGPU AMD Plane:
 Maintainers:
  - Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
 Files:
  - tests/amdgpu/amd_plane.c

AMDGPU AMD Link:
 Maintainers:
  - Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
 Files:
  - tests/amdgpu/amd_link_settings.c
  - tests/amdgpu/amd_dp_dsc.c
  - tests/amdgpu/amd_hotplug.c

AMDGPU AMD Color:
 Maintainers:
  - Stylon Wang <stylon.wang@amd.com>
 Reviewers:
  - Sunpeng Li (Leo) <Sunpeng.Li@amd.com>
  - Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
 Files:
  - tests/amdgpu/amd_color.c
  - tests/amdgpu/amd_max_bpc.c

AMDGPU AMD content protection:
 Maintainers:
  - Stylon Wang <stylon.wang@amd.com>
 Reviewers:
  - Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
 Files:
  - tests/amdgpu/amd_assr.c

AMDGPU VRR/Freesync:
 Maintainers:
  - Stylon Wang <stylon.wang@amd.com>
  - Solomon Chiu <Solomon.Chiu@amd.com>
 Reviewers:
  - Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
  - Aurabindo Pillai <aurabindo.pillai@amd.com>
 Files:
  - tests/amdgpu/amd_vrr_range.c

All KMS tests:
 Reviewers:
  - Mark Yacoub <markyacoub@chromium.org>
 Files:
  - tests/kms_*

V3D tests:
 Reviewers:
  - Melissa Wen <mwen@igalia.com>
 Files:
  - tests/v3d_*

THE REST:
 Maintainers:
  - Arkadiusz Hiler <arek@hiler.eu>
  - Petri Latvala <petri.latvala@intel.com>
 Lists:
  - igt-dev@lists.freedesktop.org
 Issue Trackers:
  - https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues
 Patch Trackers:
  - https://patchwork.freedesktop.org/project/igt/series/?ordering=-last_updated
 Repositories:
  - git@gitlab.freedesktop.org:drm/igt-gpu-tools.git
 Files:
  - "*"
  - "*/"

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: maintainers.py --]
[-- Type: text/x-python, Size: 1300 bytes --]

#!/usr/bin/env python3

import fnmatch
import itertools
import sys

import strictyaml
import whatthepatch

maintainers_schema = strictyaml.MapPattern(strictyaml.Str(), strictyaml.Map({
    strictyaml.Optional('Status'): strictyaml.Enum(["Supported", "Maintained"]),
    strictyaml.Optional('Maintainers'): strictyaml.Seq(strictyaml.Email()),
    strictyaml.Optional('Reviewers'): strictyaml.Seq(strictyaml.Email()),
    strictyaml.Optional('Lists'): strictyaml.Seq(strictyaml.Email()),
    strictyaml.Optional('Issue Trackers'): strictyaml.Seq(strictyaml.Url()),
    strictyaml.Optional('Patch Trackers'): strictyaml.Seq(strictyaml.Url()),
    strictyaml.Optional('Repositories'): strictyaml.Seq(strictyaml.Str()),
    strictyaml.Optional('Files'): strictyaml.Seq(strictyaml.Str()),
}))

with open('MAINTAINERS') as f:
    maintainers = strictyaml.load(f.read(), maintainers_schema).data

with open(sys.argv[1]) as f:
    patch_files = list(set(itertools.chain.from_iterable((diff.header.old_path, diff.header.new_path) for diff in whatthepatch.parse_patch(f.read()))))

    for filename in patch_files:
        for k, v in maintainers.items():
            for pattern in v.get('Files', []):
                if fnmatch.fnmatch(filename, pattern):
                    print(f'{k}: {pattern} matches')

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

[Rodrigo Siqueira Jordao]

On 2022-03-02 07:56, Jani Nikula wrote:
> On Wed, 02 Mar 2022, Petri Latvala <petri.latvala@intel.com> wrote:
>> On Mon, Feb 07, 2022 at 02:31:03PM +0200, Jani Nikula wrote:
>>> FWIW, if I were to do this, I'd do it in yaml and implement it in
>>> python+strictyaml with a schema. No need to import a monster perl parser
>>> from kernel or implement our own.
>>
>> I really like this suggestion. The perl script from kernel is
>> completely overkill for IGT purposes where it would be mostly (or
>> 100%) used to collect Cc fields to patches for people volunteering for
>> doing review.
> 
> Last week I hacked a bit on what my suggestion would look like, but
> decided I really don't have time for this. Anyway, attached is what I
> put together in less than an hour in case anyone wants to pick it up
> from here.
> 
> You'll need strictyaml and whatthepatch from pip. The latter could
> perhaps be replaced with something better but it fit the bill now and it
> took only minutes to start using. Using strictyaml with a schema is a
> really powerful tool here.
> 
> Put the attachments in igt root (they're not even patches, sorry), and
> try:
> 
> $ ./maintainers.py some-igt.patch
> 
> The MAINTAINERS used here is just a conversion from some earlier patch,
> don't put too much weight on the content, rather the format.
> 
> BR,
> Jani.
> 
> 

Hi Jani,

I'm inclined to avoid creating an IGT-specific solution because we will 
need to maintain it, which will add more effort for IGT developers 
(manage dependencies, bugs, etc.). However, I also agree that copy & 
paste other people's code will end up in a similar issue; for this 
reason, I suggested a different approach in the second patch of the 
following patchset:

  https://patchwork.freedesktop.org/series/99534/

Instead of copying the get_maintainers script to IGT, I created a thin 
layer that automatically downloads get_maintainers and invokes it with a 
few options. What do you think about this approach?

Thanks
Siqueira

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

[Petri Latvala]

On Wed, Mar 16, 2022 at 09:10:12AM -0400, Rodrigo Siqueira Jordao wrote:
> 
> 
> On 2022-03-02 07:56, Jani Nikula wrote:
> > On Wed, 02 Mar 2022, Petri Latvala <petri.latvala@intel.com> wrote:
> > > On Mon, Feb 07, 2022 at 02:31:03PM +0200, Jani Nikula wrote:
> > > > FWIW, if I were to do this, I'd do it in yaml and implement it in
> > > > python+strictyaml with a schema. No need to import a monster perl parser
> > > > from kernel or implement our own.
> > > 
> > > I really like this suggestion. The perl script from kernel is
> > > completely overkill for IGT purposes where it would be mostly (or
> > > 100%) used to collect Cc fields to patches for people volunteering for
> > > doing review.
> > 
> > Last week I hacked a bit on what my suggestion would look like, but
> > decided I really don't have time for this. Anyway, attached is what I
> > put together in less than an hour in case anyone wants to pick it up
> > from here.
> > 
> > You'll need strictyaml and whatthepatch from pip. The latter could
> > perhaps be replaced with something better but it fit the bill now and it
> > took only minutes to start using. Using strictyaml with a schema is a
> > really powerful tool here.
> > 
> > Put the attachments in igt root (they're not even patches, sorry), and
> > try:
> > 
> > $ ./maintainers.py some-igt.patch
> > 
> > The MAINTAINERS used here is just a conversion from some earlier patch,
> > don't put too much weight on the content, rather the format.
> > 
> > BR,
> > Jani.
> > 
> > 
> 
> Hi Jani,
> 
> I'm inclined to avoid creating an IGT-specific solution because we will need
> to maintain it, which will add more effort for IGT developers (manage
> dependencies, bugs, etc.).


We don't have a need for 90% of the kernel get_maintainers.pl features
though. IGT's needs are very simple and code should be very simple
likewise.


-- 
Petri Latvala

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

[Jani Nikula]

On Wed, 16 Mar 2022, Rodrigo Siqueira Jordao <rjordrigo@amd.com> wrote:
> On 2022-03-02 07:56, Jani Nikula wrote:
>> On Wed, 02 Mar 2022, Petri Latvala <petri.latvala@intel.com> wrote:
>>> On Mon, Feb 07, 2022 at 02:31:03PM +0200, Jani Nikula wrote:
>>>> FWIW, if I were to do this, I'd do it in yaml and implement it in
>>>> python+strictyaml with a schema. No need to import a monster perl parser
>>>> from kernel or implement our own.
>>>
>>> I really like this suggestion. The perl script from kernel is
>>> completely overkill for IGT purposes where it would be mostly (or
>>> 100%) used to collect Cc fields to patches for people volunteering for
>>> doing review.
>> 
>> Last week I hacked a bit on what my suggestion would look like, but
>> decided I really don't have time for this. Anyway, attached is what I
>> put together in less than an hour in case anyone wants to pick it up
>> from here.
>> 
>> You'll need strictyaml and whatthepatch from pip. The latter could
>> perhaps be replaced with something better but it fit the bill now and it
>> took only minutes to start using. Using strictyaml with a schema is a
>> really powerful tool here.
>> 
>> Put the attachments in igt root (they're not even patches, sorry), and
>> try:
>> 
>> $ ./maintainers.py some-igt.patch
>> 
>> The MAINTAINERS used here is just a conversion from some earlier patch,
>> don't put too much weight on the content, rather the format.
>> 
>> BR,
>> Jani.
>> 
>> 
>
> Hi Jani,
>
> I'm inclined to avoid creating an IGT-specific solution because we will 
> need to maintain it, which will add more effort for IGT developers 
> (manage dependencies, bugs, etc.). However, I also agree that copy & 
> paste other people's code will end up in a similar issue; for this 
> reason, I suggested a different approach in the second patch of the 
> following patchset:
>
>   https://patchwork.freedesktop.org/series/99534/
>
> Instead of copying the get_maintainers script to IGT, I created a thin 
> layer that automatically downloads get_maintainers and invokes it with a 
> few options. What do you think about this approach?

In the end, it's all up to the IGT maintainers, what they think is the
most sensible option, and what they're willing to take on. It's not up
to me, I'm just offering my opinion, and even some code to support that
opinion.

Re-using kernel's get_maintainer.pl also has a non-zero maintenance
effort related to it. Upstream does not support using get_maintainer.pl
even for downstream kernel forks (*), let alone non-kernel
projects. It's not a general purpose tool. If you hit problems with it,
you get to debug a monster perl script *and* the shell script to use
it. And then potentially work around the issues in IGT because upstream
doesn't care.


BR,
Jani.


(*) I've tried submitting changes to that effect.

-- 
Jani Nikula, Intel Open Source Graphics Center