[igt-dev] [RFC i-g-t 1/1] MAINTAINERS: Introduce MAINTAINERS file
Petri Latvala
petri.latvala at intel.com
Wed Mar 2 12:09:06 UTC 2022
On Mon, Feb 07, 2022 at 02:31:03PM +0200, Jani Nikula wrote:
> On Thu, 03 Feb 2022, Rodrigo Siqueira Jordao <rjordrigo at 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 at hiler.eu>
> >>> Cc: Petri Latvala <petri.latvala at intel.com>
> >>> Cc: Mark Yacoub <markyacoub at google.com>
> >>> Cc: Jessica Zhang <quic_jesszhan at quicinc.com>
> >>> Cc: Abhinav Kumar <quic_abhinavk at quicinc.com>
> >>> Cc: Melissa Wen <mwen at igalia.com>
> >>> Cc: Sean Paul <seanpaul at chromium.org>
> >>> Cc: Harry Wentland <harry.wentland at amd.com>
> >>> Cc: Sun Peng Li(Leo) <sunpeng.li at amd.com>
> >>> Cc: Chao-kai Wang (Stylon) <stylon.wang at amd.com>
> >>> Cc: Wayne Lin <wayne.lin at amd.com>
> >>> Cc: Nicholas Choi <nicholas.choi at amd.com>
> >>> Cc: Martin Peres <martin.peres at mupuf.org>
> >>> Cc: Aurabindo Pillai <aurabindo.pillai at amd.com>
> >>> Cc: Bhawanpreet Lakha <bhawanpreet.lakha at amd.com>
> >>> Cc: Qingqing Zhuo (Lilian) <qingqing.zhuo at amd.com>
> >>> Cc: Solomon Chiu <solomon.chiu at amd.com>
> >>> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
> >>
> >>
> >> A tentative ack on this effort from me, for getting more contact
> >> points formally documented.
> >>
> >> As for the implementation of it, I know this is copied from the kernel
> >> so I know the reason why they're there, but reduce the useless
> >> complexity in the documentation comment like the type of version
> >> control in a subtree, and things that just aren't true for IGT, like
> >> asking for testing from 4 or 5 people.
> >
> > 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
More information about the igt-dev
mailing list