linux-kernel - Re: [PATCH] docs: media: document media multi-committers rules and process

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241127133938.GI31095@pendragon.ideasonboard.com>
Date: Wed, 27 Nov 2024 15:39:38 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: linux-media@...r.kernel.org, Jonathan Corbet <corbet@....net>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	workflows@...r.kernel.org, Hans Verkuil <hverkuil@...ll.nl>
Subject: Re: [PATCH] docs: media: document media multi-committers rules and
 process

On Wed, Nov 27, 2024 at 12:54:15PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 27 Nov 2024 10:39:48 +0100 Mauro Carvalho Chehab escreveu:
> 
> > > This workflow doesn't apply to patch submitters who are not allowed to
> > > send pull requests and who don't have direct commit access. I thought
> > > these submitters are the main audience of this document. In that case, I
> > > think moving the next section that explains the e-mail workflow before
> > > the "Media development workflow" section (which should likely be renamed
> > > to make it clear that it is about merging patches, not developing them)
> > > would be best. The "Review Cadence" section could also be folded in
> > > there, to give a full view of what a submitter can expect.
> > > 
> > > This would also have the advantage of introducing the linuvtv.org
> > > patchwork instance, which you reference above. Documents are more
> > > readable when they introduce concepts first before using them.  
> > 
> > Will try to do such change at v2.
> 
> Actually, both workflows (a) and (b) apply to the ones that can't
> send pull requests or push at media-committers.git:
> 
> ---
> 
> a. Normal workflow: patches are handled by subsystem maintainers::
> 
>      +------+   +---------+   +-------+   +-----------------------+   +---------+
>      |e-mail|-->|patchwork|-->|pull   |-->|maintainers merge      |-->|media.git|
>      +------+   +---------+   |request|   |in media-committers.git|   +---------+
>                               +-------+   +-----------------------+
> 
>    For this workflow, pull requests can be generated by a committer,
>    a previous committer, subsystem maintainers or by a couple of trusted
>    long-time contributors. If you are not in such group, please don't submit
>    pull requests, as they will likely be ignored.
> 
> b. Committers' workflow: patches are handled by media committers::
> 
>      +------+   +---------+   +--------------------+   +-----------+   +---------+
>      |e-mail|-->|patchwork|-->|committers merge at |-->|maintainers|-->|media.git|
>      +------+   +---------+   |media-committers.git|   |approval   |   +---------+
>                               +--------------------+   +-----------+
> 
> ---
> 
> No matter who sent an e-mail, this will be picked by patchwork and either
> be part of a PR or a MR, depending on who picked it.

Today the "normal" workflow for contributors who don't send pull
requests is that you or Hans will pick their patches from the list.
That's why I mentioned that neither of the above workflows apply there.
Now, if we consider that you and Hans will keep doing that for some
patches, and merge them using the committers workflow (where you would
handle both steps of merging in the shared tree and giving the
maintainer approval), it's true that the normal workflow would be one of
the two above.

Looking at the pull requests sent to the list over the past twelve
months, we have

     32 Sakari Ailus
     24 Hans Verkuil
     22 Laurent Pinchart
     21 Sebastian Fricke
      7 Sean Young
      7 Hans de Goede
      4 Stanimir Varbanov
      1 Shuah Khan

I expect people in that list to get commit rights either from the very
beginning or very soon after. The committer workflow (if we consider it
as including how you and Hans will continue picking patches from the
list) will be the new norm. how about flipping things and listing it as
a), and then name b) the "Pull request workflow" instead of the "Normal
workflow" ? I would even go as far as proposing documenting the pull
request workflow as legacy.

-- 
Regards,

Laurent Pinchart