2 kirigami fixes for a point release

[Ben Cooksley]

On Mon, Feb 17, 2020 at 10:43 AM Albert Astals Cid <aacid at kde.org> wrote:
>
> El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va escriure:
> > On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > > This is their fault, they as a distribution have decided to support a random
> > > KDE Frameworks version for longer than we do support it, so they are the
> > > ones that should be the job of supporting it.
> > >
> > > It's like you are trying to say we should be doing the distributions jobs,
> > > what we should be doing is doing our job which is making the best software
> > > we can, not spending time accomodating decisions that somebody else took
> > > for us, and since distributions often only bring us pain in the shape of
> > > not updating versions, etc. IMHO what we should be doing is moving away
> > > from distributions model and more into the snap/flatpak model in which we
> > > control what we give our users.
> > >
> > > Sadly flatpak doesn't work for non applications and snap is
> > > Ubuntu-only-not-really-but-yes-really so for Plasma this doesn't really
> > > solver the problem so maybe we should just finally tell our users to start
> > > using the good distributions if they care about their user experience. By
> > > good meaning those with a rolling KDE software suite or those that actually
> > > do backport fixes to the version they have randomly decided to lock onto.
> >
> > At the same time, we can only successfully convince distributions to upgrade
> > to the monthly KF5 releases if they are stable and don't come with
> > regressions. I believe this is true for most of the frameworks, but I'm not so
> > sure about kirigami/qqc2-desktop-style, based on what I hear (not just the
> > recent issue).
> >
> > Before blaming distros, I believe we have our own backyard to take care of,
> > with for sure more systematic use of code reviews and possibly more automated
> > testing, for those frameworks (for the latter I guess that QtQuick doesn't
> > make it easy, but that's part of the problem...).
>
> Maybe i explain myself wrongly, i'm not blaming distros at all.
>
> They made a decision, we/I may agree with them or not, that's *my/our* problem, what I was disagreeing is to us having to do extra work because someone elses (the distros) decision.

Unfortunately users will sadly blame us, saying KDE software is
buggy/broken/etc.
It therefore falls on us to apply pressure on the distributions making
bad decisions and make them correct them.

Those distributions that provide a bad experience to our users, and
refuse to fix it, are working against us and the goals we are trying
to achieve.

(I'm not saying that we should bow down to flawed, short sighted and
broken distribution policies here, if anyone is bending it should be
their policies bending down to us)

>
> And yes, totally, we need more autotests, and moving to gitlab so tests are finally run *before* merging stuff.

That will come once we have migrated code management and review to Gitlab yes.
It wouldn't have helped in the case of Kirigami sadly as there are no
unit tests for the things which were broken, but i'm sure it will help
in other areas for sure.

>
> Cheers,
>   Albert

Cheers,
Ben

>
> >
> >
>
>
>
>