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

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

On Thu, Sep 26, 2024 at 01:43:10PM +0200, Hans Verkuil wrote:
> On 26/09/2024 13:35, Mauro Carvalho Chehab wrote:
> > Em Thu, 26 Sep 2024 14:13:07 +0300 Laurent Pinchart escreveu:
> > 
> >>>>> 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.
> > 
> > Nobody like rebases, including subsystem maintainers. A rebase means

I'm glad we at least agree on that :-)

> > lots of manual work that we would very much prefer not to do it.
> > 
> > You don't want rebases, fine. There shouldn't be any rebases if every
> > committer ensures that each patch they merged were properly 
> > reviewed/accepted and have the proper license and tags, including
> > SPDX, SoBs, A-B, R-B, etc.
> > 
> > Yet, if a committer screws up somehow (intentionally or not), subsystem 
> > maintainers will handle it the way they think it is the best, deciding 
> > either to rebases or revert, depending on the case.
> 
> We just need to have the rebase option as a last resort. The CI should help
> to prevent rebases, and if we do need to rebase, we need to look whether a
> better/new check should be added to the CI to prevent that in the future.
> 
> Especially in the beginning things may slip through (I made mistakes when I
> started as co-maintainer!), but let's just learn from the mistakes, improve
> the CI and processes, and after 2-3 kernel cycles we take another look where
> we are.
> 
> It doesn't have to be perfect from the start, and as long as we continuously
> improve the process, I'm happy.

Incremental improvements are crucial. For this reason, I would like
every rebase to be discussed with core committers, so that we all
understand the issues and have a change to improve the tools to ensure
they won't happen again (malicious behaviour is a different case). Can
we try that, and handle rebases with a consensus-seeking process ?

> So let's all relax, take a nice cup of tea/coffee/wine/beer/whisky/etc. and
> raise it to Ricardo for doing the great work on the CI system, since that was
> a very important step forward!

Ricardo has done an amazing job there, I'm really grateful. Sebastian
also deserves big kudos, and we should be thankful for all the other
contributions. I'm personally thankful to you and Mauro for agreeing to
move forward. There's no secret that I'd like a faster pace (possibly
due to all the accumulated frustrations over the years), but there is
clear progress and I want to acknowledge that.

-- 
Regards,

Laurent Pinchart