Message-ID: <aKhB6zrtRKwbAZ-s@valkosipuli.retiisi.eu>
Date: Fri, 22 Aug 2025 10:09:47 +0000
From: Sakari Ailus <sakari.ailus@....fi>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	Hans Verkuil <hverkuil@...all.nl>,
	Ricardo Ribalda <ribalda@...omium.org>
Subject: Re: [PATCH v4 3/5] docs: media: update maintainer-entry-profile for
 multi-committers

Hi Mauro,

On Fri, Aug 22, 2025 at 11:31:59AM +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Aug 2025 08:59:29 +0000
> Sakari Ailus <sakari.ailus@....fi> escreveu:
> 
> > Hi Mauro,
> > 
> > On Fri, Aug 22, 2025 at 10:23:46AM +0200, Mauro Carvalho Chehab wrote:
> > > Em Thu, 21 Aug 2025 12:26:18 +0000
> > > Sakari Ailus <sakari.ailus@....fi> escreveu:

...

> > > What about this:
> > > 
> > > <text>
> > > The Linux Media Community (aka: the LinuxTV Community) consist of developers 
> > > who work with the Linux Kernel media subsystem, together with users who
> > > benefit from such develoment and help testing the developed code.  
> > 
> > How about, with slight modifications:
> > 
> > The Linux Media Community (aka: the LinuxTV Community) is formed of
> > developers working on Linux Kernel Media Subsystem, together with users.
> 
> Works for me, although I prefer keep mentioning about the important
> role that users play on help testing drivers.

How about then:

The Linux Media Community (aka: the LinuxTV Community) is formed of
developers working on Linux Kernel Media Subsystem, together with users who
also play an important role in testing the code.

> 
> > 
> > > 
> > > They work on the top of the Media tree, which has code to support a    
> > > variety of devices: stream capture, analog and digital TV streams, cameras,
> > > remote controllers, HDMI CEC and media pipeline control.
> > > 
> > > The Media tree is mainly responsible to be the main source of the
> > > code under development with the contents of those directories:
> > > 
> > >   - drivers/media
> > >   - drivers/staging/media
> > >   - Documentation/admin-guide/media
> > >   - Documentation/driver-api/media
> > >   - Documentation/userspace-api/media
> > >   - Documentation/devicetree/bindings/media/\ [1]_
> > >   - include/media
> > > </text>
> > >   
> > > >   
> > > > >  
> > > > >    - drivers/media
> > > > >    - drivers/staging/media
> > > > > @@ -27,19 +28,158 @@ It covers, mainly, the contents of those directories:
> > > > >  Both media userspace and Kernel APIs are documented and the documentation
> > > > >  must be kept in sync with the API changes. It means that all patches that
> > > > >  add new features to the subsystem must also bring changes to the
> > > > > -corresponding API files.
> > > > > +corresponding API documentation files.    
> > > > 
> > > > I'd drop " files" as the documentation is split between C source code files
> > > > and ReST nowadays.  
> > > 
> > > OK.
> > >   
> > > > > -Due to the size and wide scope of the media subsystem, media's
> > > > > -maintainership model is to have sub-maintainers that have a broad
> > > > > -knowledge of a specific aspect of the subsystem. It is the sub-maintainers'
> > > > > -task to review the patches, providing feedback to users if the patches are
> > > > > +Due to the size and wide scope of the media subsystem, the media's
> > > > > +maintainership model is to have committers that have a broad knowledge of    
> > > > 
> > > > Maintainership or maintenance?
> > > > 
> > > > s/is to have/recognises/ ?  
> > > 
> > > OK.
> > >    
> > > > > +a specific aspect of the subsystem. It is the committers' task to
> > > > > +review the patches, providing feedback to users if the patches are
> > > > >  following the subsystem rules and are properly using the media kernel and
> > > > >  userspace APIs.
> > > > >  
> > > > > -Patches for the media subsystem must be sent to the media mailing list
> > > > > -at linux-media@...r.kernel.org as plain text only e-mail. Emails with
> > > > > -HTML will be automatically rejected by the mail server. It could be wise
> > > > > -to also copy the sub-maintainer(s).
> > > > > +Media committers
> > > > > +----------------
> > > > > +
> > > > > +In the media subsystem, there are experienced developers who can push
> > > > > +patches directly to the development tree. These developers are called
> > > > > +Media committers and are divided into the following categories:
> > > > > +
> > > > > +- Committers:
> > > > > +    contributors for one or more drivers within the media subsystem.
> > > > > +    They can push changes to the tree that do not affect the core or ABI.    
> > > > 
> > > > Question to Ricardo -- sorry if I already have asked this: can this be
> > > > enforced?
> > > >   
> > > > > +
> > > > > +- Core committers:
> > > > > +    responsible for part of the media core. They are typically
> > > > > +    responsible for one or more drivers within the media subsystem, but, besides
> > > > > +    that, they can also merge patches that change the code common to multiple
> > > > > +    drivers, including the kernel internal API.    
> > > > 
> > > > This doesn't say clearly whether e.g. the V4L2 or MC frameworks are
> > > > included or not. I think they should be and this should be mentioned. Same
> > > > for videobuf2.  
> > > 
> > > The problem of specifying what the core via frameworks, vb2, etc is that
> > > this would require constant maintainance. Core is everything that is not
> > > inside a driver for an specific driver.
> > > 
> > > We called this here as "the code common to multiple drivers". For me it
> > > is clear, but if you have a better generic term, I'm all ears.  
> > 
> > How about:
> > 
> > - Core committers:
> >     responsible for part of the Media Core, including V4L2, Media
> >     controller, Videobuf2, CEC and DVB frameworks. They are typically
> >     responsible for one or more drivers within the Media Subsystem, but,
> >     besides that, they can also merge patches that change the code common
> >     to multiple drivers, including the kernel internal API.
> > 
> > I think we should define Media Subsystem, Media Core and possibly Media
> > Community in the glossary but I'd do that after merging this set.
> 
> You forgot remote controllers there ;-)
> 
> Btw, that's exactly my point: when we enumerate things, we tend to forget
> about something, and, when new stuff gets add, we need to remember to
> add here.

The text above does not imply something isn't part of Media Core even if
not listed. But of course Remote Controller should have been in the above
list. Adding that results in:

- Core committers:
    responsible for part of the Media Core, including V4L2, Media
    controller, Videobuf2, Remote Controller, CEC and DVB frameworks. They
    are typically responsible for one or more drivers within the Media
    Subsystem, but, besides that, they can also merge patches that change
    the code common to multiple drivers, including the kernel internal API.

> 
> > 
> > >   
> > > >   
> > > > > +
> > > > > +- Subsystem maintainers:
> > > > > +    responsible for the subsystem as a whole, with access to the
> > > > > +    entire subsystem.
> > > > > +
> > > > > +    API/ABI changes are done via consensus between subsystem maintainers\ [2]_.
> > > > > +
> > > > > +    Only subsystem maintainers push changes that affect the userspace
> > > > > +    API/ABI. Committers may push ABI/API changes on their commits if they
> > > > > +    have approvals from subsystem maintainers.
> > > > > +
> > > > > +All media committers shall explicitly agree with the Kernel development process
> > > > > +as described at Documentation/process/index.rst and to the Kernel
> > > > > +development rules inside the Kernel documentation, including its code of
> > > > > +conduct.    
> > > > 
> > > > Is there a need to mention this? Aren't people generally expected to
> > > > follow the process anyway?  
> > > 
> > > There's a big difference between "generally expected" and "have to agree".
> > > The goal here is really to prevent having bad committers as we had in the
> > > past on our previous multicommiters model before we moved to git. If this
> > > ever have again, by having an explicit agreement, one cannot deny he/she
> > > didn't know the rules.  
> > 
> > Fair enough. Either way, enforment is discretionary so I think this is
> > fine -- mistakes tend to happen, to everybody, at least in some extent.
> 
> Yeah, mistakes can happen. What we want to cover is intentional misbehavior.

I agree. I hope this will remain a theoretical possibility though.

-- 
Kind regards,

Sakari Ailus

Powered by blists - more mailing lists