lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241129112952.1f0c9222@foz.lan>
Date: Fri, 29 Nov 2024 11:29:52 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Hans Verkuil <hverkuil@...all.nl>, linux-media@...r.kernel.org, Jonathan
 Corbet <corbet@....net>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, workflows@...r.kernel.org
Subject: Re: [PATCH] docs: media: document media multi-committers rules and
 process

Em Thu, 28 Nov 2024 21:07:07 +0200
Laurent Pinchart <laurent.pinchart@...asonboard.com> 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.

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@...nel.org>

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@...r.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::
 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ