All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Rodrigo Siqueira Jordao <rjordrigo@amd.com>,
	Petri Latvala <petri.latvala@intel.com>
Cc: Qingqing Zhuo <qingqing.zhuo@amd.com>,
	igt-dev@lists.freedesktop.org, Sean Paul <seanpaul@chromium.org>,
	Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>,
	Mark Yacoub <markyacoub@google.com>
Subject: Re: [igt-dev] [RFC i-g-t 1/1] MAINTAINERS: Introduce MAINTAINERS file
Date: Wed, 16 Mar 2022 15:39:54 +0200	[thread overview]
Message-ID: <8735jinhhx.fsf@intel.com> (raw)
In-Reply-To: <4ce3234e-493b-8ee9-07b8-148be2a9e917@amd.com>

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

  parent reply	other threads:[~2022-03-16 13:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 14:28 [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT Rodrigo Siqueira
2022-01-31 14:28 ` [igt-dev] [RFC i-g-t 1/1] MAINTAINERS: Introduce MAINTAINERS file Rodrigo Siqueira
2022-02-03 11:03   ` Petri Latvala
2022-02-03 14:35     ` Harry Wentland
2022-02-03 18:56     ` Rodrigo Siqueira Jordao
2022-02-07 12:31       ` Jani Nikula
2022-03-02 12:09         ` Petri Latvala
2022-03-02 12:56           ` Jani Nikula
2022-03-16 13:10             ` Rodrigo Siqueira Jordao
2022-03-16 13:29               ` Petri Latvala
2022-03-16 13:39               ` Jani Nikula [this message]
2022-01-31 15:11 ` [igt-dev] [RFC i-g-t 0/1] Introduce MAINTAINERS file to IGT Sean Paul
2022-01-31 18:19   ` Mark Yacoub
2022-02-03  9:18     ` Petri Latvala
2022-02-02 16:23   ` Harry Wentland
2022-01-31 15:12 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2022-01-31 16:19 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2022-02-03 12:50 ` [igt-dev] [RFC i-g-t 0/1] " Melissa Wen
2022-02-03 18:59   ` Rodrigo Siqueira Jordao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735jinhhx.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=bhawanpreet.lakha@amd.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=markyacoub@google.com \
    --cc=petri.latvala@intel.com \
    --cc=qingqing.zhuo@amd.com \
    --cc=rjordrigo@amd.com \
    --cc=seanpaul@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.