Re: Revert of my compositing rework patches
Roman Gilg <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kwin |
|---|---|
| Message-ID | <CAJcyoyvNWcvmHCq71DJa4OVpzAi1C13xwxcGBKRqYC9=z8RB_w@mail.gmail.com> |
On Wed, Jan 15, 2020 at 6:52 PM David Edmundson <[email protected]> wrote: > > On Wed, Jan 15, 2020 at 5:28 PM Roman Gilg <[email protected]> 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. I don't believe a mere branch will just cut it. This will relax the situation short-term but sooner or later the same problems we have now will creep into this branch too. > > 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? I am relatively comfortable with the patchset from a technical side given the knowledge I currently possess. I don't know what "user-facing impact" means here, the patches make only sense together. Independent of that though: this is not about risk aversion but risk acceptance. > Regards > > David