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

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

Em Thu, 26 Sep 2024 13:24:48 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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 <sakari.ailus@linux.intel.com> 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. 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. 

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. 

Thanks,
Mauro