[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: 2 kirigami fixes for a point release
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2020-02-17 8:05:03
Message-ID: CA+XidOEX2UmL_jhG95GGpFiH-hx9E36kmsqTUynP3-D8OD6qhA () mail ! gmail ! com
[Download RAW message or body]

On Mon, Feb 17, 2020 at 10:43 AM Albert Astals Cid <aacid@kde.org> wrote:
>
> El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va esc=
riure:
> > On dimanche 16 f=C3=A9vrier 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 sof=
tware
> > > we can, not spending time accomodating decisions that somebody else t=
ook
> > > 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 aw=
ay
> > > from distributions model and more into the snap/flatpak model in whic=
h 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 real=
ly
> > > 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 ac=
tually
> > > do backport fixes to the version they have randomly decided to lock o=
nto.
> >
> > At the same time, we can only successfully convince distributions to up=
grade
> > 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 aut=
omated
> > testing, for those frameworks (for the latter I guess that QtQuick does=
n'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* pr=
oblem, what I was disagreeing is to us having to do extra work because some=
one 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 a=
re finally run *before* merging stuff.

That will come once we have migrated code management and review to Gitlab y=
es.
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

>
> >
> >
>
>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]