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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Sep 26, 2024 at 01:06:15PM +0200, Mauro Carvalho Chehab wrote:
> 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.

The comment about scaling was about reviews at PR time, not about
drivers/staging/.

> Also, we prefer drivers going directly to drivers/media, so staging
> should be used only on unusual cases.

No disagreement there, and I think that accepting new drivers in staging
is something worth discussing when it happens. Nobody said drivers
should be sneaked in there.

> 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.

I certainly disagree, yes. I won't comment further, I think you know my
position well enough, and I'm certain the majority of the community is
also against rebases.

-- 
Regards,

Laurent Pinchart