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