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

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

Em Thu, 26 Sep 2024 13:30:02 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> On Thu, Sep 26, 2024 at 12:38:15AM +0200, Mauro Carvalho Chehab wrote:
> > 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.  
> 
> I think those could still be pushed directly, but I'm fine with a pull
> request for the time being. If the concern is that you'd like to have a
> look at the driver first, in the long run I'd rather ping you for a
> review and then push once you give an ack. We should move away from
> reviews at pull request time, they don't scale.

There aren't many new stage drivers, so this doesn't need to scale.

Also, we prefer drivers going directly to drivers/media, so staging
should be used only on unusual cases. Subsystem maintainers should
give a final word if a driver should be merged there or directly on
drivers/media.

> 
> > > > > 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.   
> 
> That's also a useful goal of course. If we can kill two birds with one
> stone, that's a good outcome.
> 
> > 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].  
> 
> That I don't like. We want people working on the media subsystem to test
> the very latest code, and to base their work on the tree that their
> patches will land in. Otherwise there will be conflicts, and the risk of
> conflict will increase as we pick up pace with the new workflow and
> merge patches faster.

This is unavoidable: in the beginning committers may (and will) make
mistakes, as this is a different workflow. As we keep adding more committers, 
more mistakes may happen, specially for the newbies.

So, we need to protect the tree where patches land in (media at 
linuxtv.org) from potential issues that might happen at the shared tree.

Besides that, conflicts are unavoidable on a multi-committers tree.

> > [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.  
> 
> Things that haven't reached a consensus should not be merged in the
> first place, and in the rare cases where it happens, a revert is fine.
> Rebases should be kept for situations where no other option is possible.

I guess we agree to disagree.

Thanks,
Mauro