2 kirigami fixes for a point release

[Ben Cooksley]

On Thu, Feb 13, 2020 at 10:00 AM Nate Graham <nate at kde.org> wrote:
>
> [+ 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:
> >> Personally I think it would be nice to have
> >> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
> >> users will be hitting it for the next few years.
> >>
> >> ---
> >>
> >> 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 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

Can we please have a list of the offending distributions?

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

Looking at the respin requests I see the following Frameworks as being
problematic:

- Kirigami
- QQC2 Desktop Style

This is only a small number of Frameworks.

>
> However buggy releases are the proximate cause, not the root cause. We
> have to ask: what causes buggy releases?

Part of the issue here is that Plasma has been known to add API to
Frameworks and then immediately, without any delay, start using it
(pretty much always breaking CI in the process)

This means that other changes are likely being pushed into Frameworks
by Plasma with very little delay as well.

Consequently this means stuff is landing in Framework repositories up
to the very moment it is released - a release that the next version of
Plasma (LTS) then depends on.

A better way of approaching this would be to freeze the Frameworks
version you are going to require API wise at an earlier point in the
Plasma development cycle. This would allow for a full Frameworks
release cycle to pass where bugs encountered during the lead up to the
Plasma release can be fixed.

This version of Frameworks would then be the one that Plasma hard depends on.

>
> 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.
>
> However because Frameworks has no explicit beta period, the only people
> performing QA are those who live on master all the time. The amount of
> time for these people to catch regressions can be as short as one day,
> for changes committed right before tagging. Even for commits at the very
> beginning of a Frameworks release cycle, there will be a maximum of one
> month before they ship to users. There simply isn't enough time to
> provide adequate QA for Frameworks releases, and the pool of people
> doing it is too small.
>

Changes with the potential to have an impact like that shouldn't be
going in a day or two before the tagging/release.

> Making users be the QA is mostly okay for rolling release distros whose
> users are willing to take on that role: regressions get found and fixed
> in the next version and users receive the fixes in one month. But this
> model breaks down for LTS release distros that freeze on a specific
> frameworks version. If the version they've frozen on is buggy, that's
> it. It's buggy forever, unless their we make point releases or their
> already overworked packagers go out of the way to search for and
> backport fixes.
>
> The Frameworks release model just doesn't fit for discrete release
> distros, especially for the LTS releases. Sometimes it works out better
> than other times, but it is a fundamental incompatibility when the
> product wants customers to ship new releases continuously, but the
> customers want the product frozen to one version with only safe bugfixes
> shipped after that.
>
> Personally I think a lengthier release cycle and discrete beta periods
> would really help Frameworks, even in the absence of interest in
> creating a product more aligned to our LTS-using customers.
>
> Nate

Regards,
Ben