2 kirigami fixes for a point release

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

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.

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