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

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

On Thu, Sep 26, 2024 at 12:53:58PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Sep 2024 13:24:48 +0300 Laurent Pinchart escreveu:
> 
> > On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> > > Em Thu, 26 Sep 2024 09:30:34 +0000 Sakari Ailus escreveu:
> > >   
> 
> > > Yet, even if the committer did an honest handling of the patch, you may 
> > > still disagree or want some changes at the original patch. On such cases, 
> > > the maintainers may decide to drop the changes and do a normal review
> > > process. They may otherwise request a patch on the top of the applied
> > > one to address the pointed issues.  
> > 
> > Let's do a revert in that case, and keep rebases for cases where having
> > content in the git history causes issues other than bisection problems.
> 
> Rebasing or not is a subsystem maintainers decision.

The job of a maintainer is to make their subsystem thrive. The power of
making decisions comes with the responsibility of cattering for the
needs of the community. In this case, I think the community wants to
avoid rebases as much as possible. Let's work together on avoiding them
by improving whatever processes need to be improved.

> Reverting pollutes
> git history upstream, and it should be done in cases were we want to 
> preserve the history upstream. On cases where the preserving the history 
> doesn't matter, a rebase is better.
> 
> There is also a bad side effect of doing:
> 
> - patch 1: some fixes with c/c stable + fixes tag
> - patch 2: revert patch 1
> - patch 3: apply patch 1 on a different way
> 
> Even with just 3 patches, this can get messy when backporting to fixes,
> as we don't want all three patches backported. We want just patch 3.
> 
> There are also cases like:
> 
> - patch 1: some fixes with c/c stable + fixes tag
> - patch 2: revert patch 1
> - patch 3: a patch needed by patch 1 to not break compilation
> - patch 4: re-apply patch 1
> 
> in this case, patch 3 (or a variant of it) may or may not needed
> to be in fixes.
> 
> This becomes even more complex if there is a pile of patches with
> some with c/c stable and some without. 

We're talking about rare cases here. Let's focus the process on avoiding
rebases. If you think a rebase is needed at some point, let's discuss it
and find consensus.

> I saw already enough badly solved merge conflicts risen on different
> trees because one change was reverted and then applied back with
> about the same content. 

-- 
Regards,

Laurent Pinchart