Revert of my compositing rework patches

[David Edmundson]

On Wed, Jan 15, 2020 at 5:28 PM Roman Gilg <subdiff at gmail.com> wrote:
>
> Hi,
>
> I offer to revert the compositing rework patches that I have landed on KWin's master branch in the last few months such that they won't be included in the 5.18 release. I have done this already in a personal branch some days ago:
> https://cgit.kde.org/clones/kwin/romangilg/kwin.git/log/?h=composite-revert

FWIW, I do appreciate the general direction and overall goal of that patchset.

I did at one point have a proposal that we start an official upstream
branch where we can work on this without the risk of hitting a
deadline. They always come quicker than you think. That's still a
viable option that we can continue. Especially if we need people to
take over Fredrick's work.

> Reverts were possible with minimal conflict resolution and runtime tests on top of this branch indicated that the revert works fine.
>
> Reasons for reverting are:
> * The Nvidia swap event patch hasn't yet landed to optimize in that case.
> * Some minor regressions had been crept up and there might be more.
> * My patches weren't formally accepted when I landed them, another maintainer complained about that.
> * I don't see a positive future for the KWin project as it is currently organized on a fundamental level. Because of this I don't want to maintain these large code changes ongoing.
>
> Simple yes/no from the other two maintainers is enough. If they both want to keep the compositing rework patches in one of them is responsible for acting on related bug reports afterwards.

If you're not comfortable with the patchset, then I'm happy to agree.
You know this series best.
What is your longer term plan with the patchset?

I think there's some changes there that are lower risk, so a revert
doesn't need to include all of them.
It's really only "Flexible composite swap and timer events" that has
the most user-facing impact?

Regards

David