On workflow

[Aleix Pol]

On Sat, Jan 18, 2020 at 11:56 AM Roman Gilg <subdiff at gmail.com> wrote:
>
> On Wed, Jan 15, 2020 at 6:52 PM David Edmundson
> <david at davidedmundson.co.uk> wrote:
> >
> > 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.
>
> 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

I'd say looking into adopting gitlab will help a ton there. Providing
multi-commit features is a big pain in Phabricator and I think that we
sometimes just want to merge them to sort this out. Being able to have
a rebaseable work branch can make a difference.

Having a kind-of-stable variant feels clunky. We want people to test
master as is. The sooner we test, the sooner it fails. If a change is
susceptible to break people's computers, we'll have to reach out to
them and get them to test our changes, but having just 3 people
actually test the latest commit will just make us less effective,
IMHO.

Aleix