From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
linux-media@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
workflows@vger.kernel.org
Subject: Re: [PATCH] docs: media: document media multi-committers rules and process
Date: Mon, 2 Dec 2024 12:24:25 +0200 [thread overview]
Message-ID: <20241202102425.GD16635@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20241129112952.1f0c9222@foz.lan>
Hi Mauro,
On Fri, Nov 29, 2024 at 11:29:52AM +0100, Mauro Carvalho Chehab wrote:
> Em Thu, 28 Nov 2024 21:07:07 +0200 Laurent Pinchart escreveu:
>
> > > With that in mind, every committer has duties of reviewing other
> > > developer's patches submitted for the drivers that they're listed as
> > > a maintainer at the MAINTAINERS file entries.
> >
> > I'm sorry but that's not a multi-committer model, it's a co-maintenance
> > model. If that's what you really want we can reopen the discussion and
> > start anew, but I don't think it's a good idea.
> >
> > As I said before, if it increases my work load, I don't want commit
> > rights. I'll keep sending pull requests, you'll have to keep processing
> > them, and patches will be merged slower. It will be a lose-lose
> > situation for everybody, you, me, contributors and users.
> >
> > Starting with a situation where we are understaffed and trying to solve
> > it by putting more work on the few people who currently keep the
> > subsystem alive doesn't sound like a winning strategy.
>
> After sleeping over it, I agree that you're partially right on this.
\o/
You should sleep more often :-D
> Doing timely reviews is orthogonal of being a committer. What defines
> if you need to do timely reviews is if you're listed or not at the
> MAINTANERS file as "M:" - e.g. if the developer is a maintainer
> (on its broader sense) or not. This applies for both PR and MR workflows.
>
> Still, if one is not fulfilling its duty as maintainer, he may end
> losing maintainership status and the corresponding committer rights.
>
> I wrote a separate patch to make it clear. See below.
>
> Thanks,
> Mauro
>
> ---
>
> [PATCH] docs: media: profile: make it clearer about maintainership duties
>
> During the review of the media committes profile, it was noticed
> that the responsibility for timely review patches was not clear:
> such review is expected that all developers listed at MAINTAINERS
> with the "M:" tag (e.g. "maintainers" on its broad sense).
>
> This is orthogonal of being a media committer or not. Such duty
> is implied at:
>
> Documentation/admin-guide/reporting-issues.rst
>
> and at the MAINTAINERS header, when it says that even when the
> status is "odd fixes", the patches will flow in.
>
> So, let make it explicit at the maintainer-entry-profile that
> maintainers need to do timely reviews.
>
> Also, while right now our focus is on granting committer rights to
> maintainers, the media-committer model may evolve in the future to
> accept other committers that don't have such duties.
>
> So, make it clear at the media-committer.rst that the duties
> related to reviewing patches from others are for the drivers
> they are maintainers as well.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
I'll comment on this on v3 of the series.
> diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst
> index 650803c30c41..6daf71bc72c1 100644
> --- a/Documentation/driver-api/media/maintainer-entry-profile.rst
> +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
> @@ -147,6 +147,11 @@ b. Committers' workflow: patches are handled by media committers::
> On both workflows, all patches shall be properly reviewed at
> linux-media@vger.kernel.org before being merged at media-committers.git.
>
> +Such patches will be timely-reviewed by developers listed as maintainers at
> +the MAINTAINERS file. Such maintainers will follow one of the above
> +workflows, e. g. they will either send a pull request or merge patches
> +directly at the media-committers tree.
> +
> When patches are picked by patchwork and when merged at media-committers,
> CI bots will check for errors and may provide e-mail feedback about
> patch problems. When this happens, the patch submitter must fix them
> diff --git a/Documentation/driver-api/media/media-committer.rst b/Documentation/driver-api/media/media-committer.rst
> index 1756a7af6353..a873ef84fbca 100644
> --- a/Documentation/driver-api/media/media-committer.rst
> +++ b/Documentation/driver-api/media/media-committer.rst
> @@ -87,9 +87,9 @@ be delegating part of their maintenance tasks.
> Due to that, to become a committer or a core committer, a consensus between
> all subsystem maintainers is required, as they all need to trust a developer
> well enough to be delegated the responsibility to maintain part of the code
> -and to properly review patches from third parties, in a timely manner and
> -keeping the status of the reviewed code at https://patchwork.linuxtv.org
> -updated.
> +and to properly review patches from third parties for the drivers they are
> +maintainers in a timely manner and keeping the status of the reviewed code
> +at https://patchwork.linuxtv.org updated.
>
> .. Note::
>
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-12-02 10:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 13:28 [PATCH] docs: media: document media multi-committers rules and process Mauro Carvalho Chehab
2024-11-26 15:19 ` Laurent Pinchart
2024-11-27 9:39 ` Mauro Carvalho Chehab
2024-11-27 11:19 ` Laurent Pinchart
2024-11-27 14:48 ` Simona Vetter
2024-11-28 11:24 ` Jani Nikula
2024-11-28 18:47 ` Mauro Carvalho Chehab
2024-11-28 21:27 ` Jani Nikula
2024-11-28 21:52 ` Simona Vetter
2024-11-29 2:21 ` Mauro Carvalho Chehab
2024-11-29 1:57 ` Mauro Carvalho Chehab
2024-11-28 18:28 ` Mauro Carvalho Chehab
2024-11-28 19:08 ` Laurent Pinchart
2024-11-27 11:54 ` Mauro Carvalho Chehab
2024-11-27 13:39 ` Laurent Pinchart
2024-11-27 15:09 ` Mauro Carvalho Chehab
2024-11-27 17:59 ` Laurent Pinchart
2024-11-27 11:59 ` Hans Verkuil
2024-11-27 13:25 ` Laurent Pinchart
2024-11-28 18:15 ` Mauro Carvalho Chehab
2024-11-28 19:07 ` Laurent Pinchart
2024-11-29 10:29 ` Mauro Carvalho Chehab
2024-12-02 10:24 ` Laurent Pinchart [this message]
2024-11-28 8:19 ` Mauro Carvalho Chehab
2024-11-28 9:31 ` Laurent Pinchart
2024-11-28 17:44 ` Mauro Carvalho Chehab
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=20241202102425.GD16635@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=corbet@lwn.net \
--cc=hverkuil@xs4all.nl \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=workflows@vger.kernel.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.