2 kirigami fixes for a point release

[Ben Cooksley]

On Mon, Feb 17, 2020 at 10:55 AM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> 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... ;)

Another option is to withdraw the privilege of pre-release access to
packages from the distributions that don't comply.

>
> > >> 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.

It's sad to hear that was the case when they released - because it
essentially means that nobody from Plasma actually cares about their
CI builds.

If that is the case, then more tests and having pre-merge CI is
unlikely to resolve the issues we've encountered here.

That's of particular note because Plasma is one of the most expensive
projects to support when it comes to CI infrastructure. To put this in
context, some of the design decisions of the current iteration of the
system were made explicitly because of how Plasma operates.
Additionally, some parts of Plasma demand specialised code within the
CI Tooling to ensure the system is in a specific state - namely a low
load - due to their tests being fragile and unable to handle other
conditions.

>
> 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
>
>

Cheers,
Ben