Message-ID: <20241127175926.GA13800@pendragon.ideasonboard.com>
Date: Wed, 27 Nov 2024 19:59:26 +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 04:09:23PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 27 Nov 2024 15:39:38 +0200 Laurent Pinchart escreveu:
> > 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.
> 
> True, but we've been following process (b) since the last merge window: we
> are generating merges at the media-committers.git. As we're maintainers, 
> the "maintainers approval" step is also handled by us, by the one that
> submitted the MR, after checking the media-ci results.
> 
> > 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.
> 
> Yes, that's the case.
> 
> > 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.
> 
> Renaming from Normal work flow to Pull request workflow makes sense.
> 
> The pull request workflow won't be legacy. Even with major contributors
> using the new workflow for "normal work", pull requests will still be
> generated for API changes.

OK, let's not mark it as deprecated, we can just rename it to "Pull
request workflow". I'd still prefer to list it as b) but won't make that
a casus belli.

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists