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

Jani Nikula jani.nikula at linux.intel.com
Wed Mar 16 13:39:54 UTC 2022


On Wed, 16 Mar 2022, Rodrigo Siqueira Jordao <rjordrigo at amd.com> wrote:
> On 2022-03-02 07:56, Jani Nikula wrote:
>> On Wed, 02 Mar 2022, Petri Latvala <petri.latvala at 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


More information about the igt-dev mailing list