Re: [ANN] Media Summit September 16th: Final Agenda (v7)

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Wed, 25 Sep 2024 22:56:53 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Mauro,
> 
> On Wed, Sep 18, 2024 at 01:23:23PM +0200, Mauro Carvalho Chehab wrote:
> > Em Wed, 18 Sep 2024 11:30:20 +0200 Sebastian Fricke escreveu:  
> > > On 18.09.2024 09:24, Mauro Carvalho Chehab wrote:  
> > > > Em Tue, 17 Sep 2024 14:52:19 +0200 Hans Verkuil escreveu:  
> > > >> On 9/17/24 11:17 AM, Sebastian Fricke wrote:    
> > > >> > Greetings,
> > > >> >
> > > >> > I remember that we wanted to still define a couple of processes for the
> > > >> > multi-committer model for which we hadn't have the time on the media
> > > >> > summit. Just would like to gather who would be interested to meet for
> > > >> > that, where we meet (probably LPC venue) and when (Laurent just told me
> > > >> > that Friday is probably a good slot for that).    
> > > >>
> > > >> Can you refresh my memory which processes need more work?    
> > > 
> > > Well I basically remember that we had a bunch of topics in our meetings
> > > that we wanted to skip in order to talk about them here.
> > > We looked at the documentation from DRM and wanted to think about
> > > equivalent policies for media.
> > > https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html#where-do-i-apply-my-patch  
> > 
> > Thanks for the pointer. Yeah, examples from other trees can be helpful when
> > improving media developers profile and writing the committers agreement,
> > even when they have a message that it is just the opposite of what we
> > we want, like this (from DRM-misc ruleset):
> > 
> > 	"Since even a broken driver is more useful than no driver minimal
> > 	 review standards are a lot lower."
> > 
> > In this particular case, for instance, as discussed at media summit, we'd
> > like to have high quality standards for stuff under drivers/media. After
> > all, we do use drivers/media/staging for low quality drivers. 
> > 
> > It it worth mentioning that committers shall not merge low quality drivers
> > nor patches for staging. If ever needed, those should be done via PRs or
> > be explicitly authorized by maintainers.  
> 
> Do you mean new drivers only, or also patches for existing staging/
> drivers ?

New drivers only. Patches for drivers already at staging can go via
committers tree.

> 
> > > Also there were topics like how to handle backports.   
> > 
> > We don't handle backports on media tree. This is up to stable maintainers.
> > Basically, we follow stable rules to the letter:
> > 
> > 	Documentation/process/stable-kernel-rules.rst
> > 
> > E. g. patches that require backports shall have the proper meta-tags 
> > (specially cc: stable and  fixes:).   
> 
> Sebastian may have meant backmerges.
> 
> > Also, we're not implementing multi-committers for fixes, just for next.
> > 
> > So, fixes shall follow the normal flow: they should be sent via PR.  
> 
> I see there's a fixes branch in the media-committers tree, does that
> mean you have agreed with Hans and Ricardo that fixes will go through
> pull requests but be pushed there for visibility ? If so, thanks for
> that, I think it will improve the experience.

Hans and I are planning to push fixes at the media-committers tree, as it
allows CI to run those, but the goal here is not about visibility - it is
just to ensure that CI will execute tests on the merged patches. 
For committers and developers, the fixes workflow remains the same:
PRs for committers and patches for developers.

-

See, the main repository is hosted at linuxtv.org. We intend to avoid 
as much as possible rebases at the media tree at linuxtv.org, on both
fixes and next branches.

The media-committers tree at fdo is focused on executing patches at CI
and should only be used by committers. All other developers should base 
their work at the repository stored at linuxtv.org[1].

[1] We are planning to have a "media" repository there, replacing the
    current "media-stage" tree.

See, the media-committers repository at fdo can be rebased. This might
happen, for instance, if we don't agree with some merge there during
our merge review or if other committers disagree with merges. On such
case, the not-accepted patches will be dropped via rebase and the patches
will need to be reviewed the normal way.

> > > > I have the same doubt. As discussed during the summit, Hans and I had some
> > > > discussions yesterday, to address a few details. For both of us the process
> > > > sounds well defined.    
> > > 
> > > I know that we scraped a lot of topics in the meeting at the media
> > > summit and I am not sure about the scope you discussed with Ricardo
> > > yesterday. So, we don't have to meet if you feel like we covered
> > > everything, just wanted to use the opportunity as long as we are all in
> > > the same place.  
> > 
> > I guess we covered everything that are needed for now. If required,
> > further discussions may happen later via e-mail and/or virtual meetings.  

Thanks,
Mauro