2 kirigami fixes for a point release

[Friedrich W. H. Kossebau]

Sorry, no time to rewrite to make this short.

Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham:
> [+ frameworks and plasma mailing lists]
> 
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va 
escriure:
> >> On another note, I have to admit I'm starting to doubt how well our LTS
> >> Plasma product works without a corresponding LTS frameworks release to
> >> support it. We can fix bugs in software that uses the Plasma release
> >> schedule till the cows come home, but if the bug is in Frameworks, users
> >> are stuck with it forever since LTS distros don't typically ship new
> >> Frameworks releases.

Yes, this has been questioned a few times. Also seeing Plasma LTS used 
together with a non-LTS Qt is a bit strange.
But somehow it seems there has not been enough pain for those using the Plasma 
LTS to change something. Possibly because distributions simply backport 
important bug fixes for KF themselves, kind of maintaining their own KF LTS 
version of the KF version they pinpointed to when they froze the ingredients 
to their OS. Because they are used to do this for other projects as well, and 
so miss this could be done in cooperation with upstream.

IMHO distributions using Plasma LTS, Plasma team & other stakeholders should 
team up here and maintain a matching LTS branch of Frameworks together at the 
central KDE repos together. Well, and a version also satisfying other clients 
of KF, like non-workspace applications from KDE.

It's not a reason to change normal KF release cycle.

BTW, we release our software in variants of GPL. We give distributions lots of 
rights by that license to do with the source code what they like, not what 
pleases us as authors. So we want to do cooperation here, not get into any 
form of commandeering them, as it starts sounding elsewhere in this thread.

If unsatisfied with the quality, make Plasma a trademark and hand it out only 
to distributions which are complying with the standards the Plasma team is 
fine with ;) 
Oh, look, an iceweasel is running over there... ;)

> >> Yes yes, they should, and all that--but they don't.
> >> 
> >> It seems like we either need to:
> >> - Work on convincing these distros to ship Frameworks versions in a
> >> rolling manner to their LTS users
> >> - Provide an LTS Frameworks product that can receive bugfixes and get
> >> point releases, to support the Plasma LTS product
> >> - Stop misleadingly offering a Plasma LTS product, since everything in
> >> it that comes from Frameworks isn't actually LTS
> > 
> > This should not matter, Plasma LTS is built on *lots* of other libraries
> > that are not LTS either.
> > 
> > If it matters is because the quality of KF5 releases are not good, that's
> > what should be fixed IMHO.
> Yes, the Frameworks 5.67 release was indeed was quite buggy and
> regression-filled from a Plasma perspective :(
> 
> However buggy releases are the proximate cause, not the root cause. We
> have to ask: what causes buggy releases?
> 
> I would argue that bugginess is baked into the Frameworks product by
> virtue of its very fast one-month release cycle and lack of beta
> periods, as there are for apps and Plasma. No matter how diligent patch
> review is, regressions always sneak in; that's why QA and beta-testing
> exist.

This assumes the master branch of KF modules serves the purpose of beta 
testing. My understanding is: it does not. And could not be, for the very 
reason you gave, too little time and too few testers.

The master branch's purpose is mainly to collect all changes for the next 
release, and serve as reference when merging dependent changes across multiple 
repos for CI. It should be in the state of "always releaseable".

Which also means patches going in should have seen a beta period by the people 
doing the patches _before_ merging them, and be well understood in their 
potential side-effects. Yes, this also means that for cross-repo/products 
developer should have first done some testing for some time with locally 
patched variants of all affected repos, if unsure about their changes (say, 
removing an unused variable is well understood in effect scope and does not 
need lots of testingi).
But by default crowd-sourcing the QA to fellow developers also working against 
current master and wanting to test-drive their own changes is not the way to 
go. For one they do not know they should test certain things and thus might 
not even get close to things, thus not do any testing, or it will conflict 
with their own work, when they cannot be sure it was their own change or 
someone else's which breaks things, wasting efforts in finding causes.

Needing longer beta test phases also hints that some product is not well 
understood or designed, and things fall apart easily. That needs fixing of the 
product itself, to become reliably maintainable and expandable.

Looking at the reasoning for the recent requests for KF tarball respins like 
"fix highly user-visible issues with scrollbars in QML-based apps" or "user-
visible UI bugs", this smells a lot like "was not tested properly before 
because no time left". Things like obvious UI regressions should have been 
catched before landing in official branches, independent of length of release 
cycle.

So: ensure QA before landing patches with KF master. With bigger changes make 
sure to have more testers before landing. If you are unsure about side-
effects, do not land a patch. If you are a reviewer/tester of a patch, tell 
what you reviewed and what your qualification to do so is (I have seen 
beginner developers waving in beginner developer patches, both missing obvious 
flaws in the patch, but seemingly reassuring each other they did proper work).
And never rush patches. If you are late for a dead-line, you are too late and 
quality of the patch will suffer from compromises on quality to make up for 
that. Just do not do that, but target instead the next release.
Things are ready when they are ready. (which also means, promise to deliver 
things only when they are done, not before, to not put yourself under 
pressure).

To do proper QA that also needs targeted testing and representative testers. 
I miss to see how that is organized with people running of git master to make 
sure that is effective beta-testing and catches 99% of regressions/flaws. And 
most such users being developers, the usage patterns might not even be 
representative.

There is at least KDE CI. to catch build errors and report unit test results. 
Now, Plasma 5.18.0 was tagged while KDE CI was not covering the 5.18 branch 
yet (because no one had triggered the global due-to-Jenkins-being-Jenkins-
needed manual build rerun after branch switching in the kde-buildmetadata, 
done only few days ago by me), and at least kde-ci-tools was in failing build 
state at the tagging time. Also is there a bigger set of repos with failing 
unit tests.

To be frank, and false politeness seems wrong here:
when it comes to bugginess here, it would rather rhyme that onto sluggishness 
for now, the one which needs to be overcome to do all basic quality work 
oneself and in time before going public with code, And master branch is the 
public for your developer fellows.

Cheers
Friedrich