2 kirigami fixes for a point release
Friedrich W. H. Kossebau
kossebau at kde.org
Sun Feb 16 21:55:05 GMT 2020
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
> >> 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
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
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
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
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
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.
More information about the release-team