2 kirigami fixes for a point release

[Nate Graham]

On 2020-02-16 14:43, Albert Astals Cid wrote:
> 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.

We already do this: it's called the Plasma LTS product. :-) It's been 
specifically created to cater to various distros' desires for an 
extended-support product they can ship to users of their own LTS releases.

But yes, I can also agree with more tests, better stability, moving to 
GitLab so tests are run before merging, etc. I think we can all agree 
with that.

However all the autotests in the world will not resolve the fundamental 
incompatibility between the Plasma LTS product, which is built around 
the release model of extended, ongoing bugfix releases, and Frameworks, 
which is built around a rolling release model with no bugfix releases at 
all.

If we don't want to change the incompatible way that Frameworks plugs 
into an LTS Plasma release, and we think our opinions regarding how a 
distro ought to ship software are valid, then I think it's time for us 
to take the lead and produce a real reference distro that shows how *we* 
think KDE software should be presented to users. Basically, we 
acknowledge that Neon is already an actual OS--the "KDE OS"--and we 
treat is as such, explicitly advertising it as a fully supported OS 
suitable for users to install and vendors to ship hardware with (as in 
fact Slimbook already does!). See also https://phabricator.kde.org/T12707.

If we don't want to be so opinionated regarding how software should be 
released--perhaps out of fear of alienating sponsors that produce LTS 
distros, for example--then maybe it's time to swallow our opinions, 
respect the way that those distro partners currently ship software even 
if we disagree with it, and adjust Frameworks to better support the 
needs of their LTS releases.


Nate