2 kirigami fixes for a point release

[Friedrich W. H. Kossebau]

Am Dienstag, 18. Februar 2020, 04:03:05 CET schrieb 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.
> 
> 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.

For one, distribution seem to be just fine with that. And it should be them to 
complain if they cannot make use of Plasma LTS to create a product endorsed by 
their distribution/operating system flavour users. Why would the package and 
use Plasma otherwise, if not to create a usable product.
They simply create their own KF LTS, by backporting patches which they define  
important enough to the version of KF they use. Like they do for all the other 
software where they pinpointed to a certain version and where upstream does 
not do a matching LTS, starting with the Linux kernel.

And as said before, the Plasma team could just maintain some LTS version of KF 
next to the normal master release branch and the normal releases. That branch 
could then even be synced with the release schedule pf Plasma LTS, incl. the 
lifespan,

Is there a list of Plasma LTS usages in distributions which are horrible 
because of important fixes to KF not being backported? Or is this more a 
theoretical problem you are afraid of seeing the current quality hick-up?

Cheers
Friedrich