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
