Hello,
I would really like to understand the policy of the schedule of major KDE component version updates in Fedora.
I know of the Plasma release schedule problem. But this is bigger apparently. The bug that forced me to leave Fedora a year ago was https://bugzilla.redhat.com/show_bug.cgi?id=1746465 . This bug was caused by a version update of KDE Frameworks, affected usability, and took over a month to fix.
Following this list, I see that breaking updates to KDE are kind of a regular occurrence: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/th...
I would guess that the component version updates mid-cycle cause the breaking updates. I would really appreciate some explanation of what the version update policy is.
Also is there *any way at all* to have a reliable KDE environment on Fedora, apart from not updating the entire system?
On Thu, Dec 31, 2020 at 6:53 PM Mikhail Ramendik mr@ramendik.ru wrote:
Hello,
I would really like to understand the policy of the schedule of major KDE component version updates in Fedora.
I know of the Plasma release schedule problem. But this is bigger apparently. The bug that forced me to leave Fedora a year ago was https://bugzilla.redhat.com/show_bug.cgi?id=1746465 . This bug was caused by a version update of KDE Frameworks, affected usability, and took over a month to fix.
Following this list, I see that breaking updates to KDE are kind of a regular occurrence:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/th...
I would guess that the component version updates mid-cycle cause the breaking updates. I would really appreciate some explanation of what the version update policy is.
Also is there *any way at all* to have a reliable KDE environment on Fedora, apart from not updating the entire system?
-- Yours, Mikhail Ramendik
Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization _______________________________________________
As a long Fedora and KDE user I usually don't enter such discussions, but nevertheless, I feel a response is in order.
Following your own anecdotal experience and some random bug report you _assume_ that your own personal experience is "regular occurrence" (your words, no mine). Let me share _my_ anecdotal experience: I run a business on Fedora and CentOS. ~20 desktops and workstations (Most running Fedora/KDE) and far too many servers and VMs. Sure, I see breakage from time to time, but my experience couldn't be any different than yours.
Heck, I'm typing this on an aging Xeon workstation that has been running Fedora/KDE since Fedora ~12-13 (!).
Does my personal anecdotal experience negate yours, simply because I have more PCs? Nope. ... and this is the exact reason I avoid making broad generalizations. E.g. " breaking updates to KDE are kind of a regular occurrence"...
Happy holidays, Gilboa
On Sun, 3 Jan 2021 at 10:24, Gilboa Davara gilboad@gmail.com wrote:
As a long Fedora and KDE user I usually don't enter such discussions, but nevertheless, I feel a response is in order.
Following your own anecdotal experience and some random bug report you _assume_ that your own personal experience is "regular occurrence" (your words, no mine). Let me share _my_ anecdotal experience: I run a business on Fedora and CentOS. ~20 desktops and workstations (Most running Fedora/KDE) and far too many servers and VMs. Sure, I see breakage from time to time, but my experience couldn't be any different than yours.
Heck, I'm typing this on an aging Xeon workstation that has been running Fedora/KDE since Fedora ~12-13 (!).
Does my personal anecdotal experience negate yours, simply because I have more PCs? Nope. ... and this is the exact reason I avoid making broad generalizations. E.g. " breaking updates to KDE are kind of a regular occurrence"...
CentOS is a very different beast from Fedora in this regard. The EPEL build of KDE uses the LTS version.
My question is specifically about drops of new major component versions. I am trying to understand why the schedule is like this, beyond the matter of Plasma releases (as the problem I had was with Framework and not Plasma).
New major component version drops are a bit of a lottery; I can well believe that for some people they always went flawlessly so far, but they are an inherent risk. If I could understand the schedule, perhaps I could come up with a mitigation strategy.
First of all, I would like to mention that I'm using Fedora KDE since F23 or F24 and I had it installed for 4+ years without re-installation on my previous laptop, so I also lean towards Golboa's experience, rather than yours. But I understand your point and the reason for the existing schedule is pretty simple, as far as I understand it, while majority of the people who are using Fedora - Gnome users and Gnome and Fedora's schedule are perfectly aligned, giving a great focus and respective amount of time to polish Fedora's Gnome experience. KDE is a minority of Fedora's users, although it's a second most popular flavour (there was a statistics published few months ago), I believe it's about 7% percent (don't quote me on that) of all fedora users, compared to 70%+ for Gnome, hence it's ... hence ... for the lack of a better work, less polished at prioritized experience? There is actually a discussion item for tomorrows (today's) call of KDE SIG to align KDE and Fedora release schedule.
Being said that, I can see a point why one would like to freeze a version of some package, but based on my personal experience, I'm not sure there is a problem that needs solving when it comes to the KDE Plasma specifically, empthesys on my experience.
One the reasons I actually use KDE Plasma with Fedora is because I would prefer several package sets to be up to date as much as possible, that includes kernel, linux-firmware, DE (plasma in this case), mesa and application set (kf and kde-apps in this case). I think generally Fedora is doing an amazing job in keeping exactly those sets at upstream level. If there is actually a need for freezing packages, I actually like what Manjaro is doing with separation of [package] and [package]-git to get latest stable or THE latest packages, maybe Fedora can do something similar and provide package or DNF group if that's possible, because, you know, dependencies.
Just wanted to provide my input. --- Best regards, Alex
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 3rd, 2021 at 22:42, Mikhail Ramendik mr@ramendik.ru wrote:
On Sun, 3 Jan 2021 at 10:24, Gilboa Davara gilboad@gmail.com wrote:
As a long Fedora and KDE user I usually don't enter such discussions, but nevertheless, I feel a response is in order.
Following your own anecdotal experience and some random bug report you assume that your own personal experience is "regular occurrence" (your words, no mine).
Let me share my anecdotal experience: I run a business on Fedora and CentOS. ~20 desktops and workstations (Most running Fedora/KDE) and far too many servers and VMs.
Sure, I see breakage from time to time, but my experience couldn't be any different than yours.
Heck, I'm typing this on an aging Xeon workstation that has been running Fedora/KDE since Fedora ~12-13 (!).
Does my personal anecdotal experience negate yours, simply because I have more PCs? Nope.
... and this is the exact reason I avoid making broad generalizations. E.g. " breaking updates to KDE are kind of a
regular occurrence"...
CentOS is a very different beast from Fedora in this regard. The EPEL
build of KDE uses the LTS version.
My question is specifically about drops of new major component
versions. I am trying to understand why the schedule is like this,
beyond the matter of Plasma releases (as the problem I had was with
Framework and not Plasma).
New major component version drops are a bit of a lottery; I can well
believe that for some people they always went flawlessly so far, but
they are an inherent risk. If I could understand the schedule, perhaps
I could come up with a mitigation strategy.
Yours, Mikhail Ramendik
Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization
kde mailing list -- kde@lists.fedoraproject.org
To unsubscribe send an email to kde-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Mikhail Ramendik wrote:
My question is specifically about drops of new major component versions.
In the context of the bug you specifically mentioned trigging this thread (kf5-kinit crashes), that was not a new major component version (arguably), but a minor release update for kde frameworks.
What we could learn from this is to emphasis again how important testing and feedback are (ie, updates-testing) before pushing these releases to stable updates. If that had been more rigorous, this bug could have been caught in time before hitting stable updates.
-- Rex
On Tue, 5 Jan 2021 at 22:04, Rex Dieter rdieter@gmail.com wrote:
In the context of the bug you specifically mentioned trigging this thread (kf5-kinit crashes), that was not a new major component version (arguably), but a minor release update for kde frameworks.
What we could learn from this is to emphasis again how important testing and feedback are (ie, updates-testing) before pushing these releases to stable updates. If that had been more rigorous, this bug could have been caught in time before hitting stable updates.
I have a specific suggestion. Could it be possible to create a time lag, something like 2-3 weeks, for any non-security KDE updates, including Frameworks, between pushing to current Fedora and previous Fedora? People on current Fedora have a greater tolerance for troublesome updates - and more ability, in general, to report bugs. My own use case, with a production workstation (not used for developing serious code), is clearly for "current minus one" Fedora.
On Wed, Jan 06, 2021 at 02:17:23PM +0000, Mikhail Ramendik wrote:
I have a specific suggestion. Could it be possible to create a time lag, something like 2-3 weeks, for any non-security KDE updates, including Frameworks, between pushing to current Fedora and previous Fedora? People on current Fedora have a greater tolerance for troublesome updates - and more ability, in general, to report bugs. My own use case, with a production workstation (not used for developing serious code), is clearly for "current minus one" Fedora.
This is similar to what the kernel folks do.
On Wed, 6 Jan 2021 at 16:24, Matthew Miller mattdm@fedoraproject.org wrote:
I have a specific suggestion. Could it be possible to create a time lag, something like 2-3 weeks, for any non-security KDE updates, including Frameworks, between pushing to current Fedora and previous Fedora? People on current Fedora have a greater tolerance for troublesome updates - and more ability, in general, to report bugs. My own use case, with a production workstation (not used for developing serious code), is clearly for "current minus one" Fedora.
This is similar to what the kernel folks do.
Yup. Could this go on the KDE SIG agenda with a reasonable chance of adopting it?..
For me this really matters a lot.
On Wed, 6 Jan 2021 at 18:02, Rex Dieter rdieter@gmail.com wrote:
I have a specific suggestion. Could it be possible to create a time lag, something like 2-3 weeks, for any non-security KDE updates, including Frameworks, between pushing to current Fedora and previous Fedora?
We can consider that, sure.
If any work is needed to cover admin/tracing overhead I would gladly volunteer. (I'm not really good at C++ though).
I really want to return to Fedora and lowering the chance of a breaking KDE update on the workstation would be just what I need.
Mikhail Ramendik wrote:
Hello,
I would really like to understand the policy of the schedule of major KDE component version updates in Fedora.
This is still largely accurate:
https://fedoraproject.org/wiki/SIGs/KDE/Update_policy
about the reasoning behind how and why.
-- Rex
Hello,
On Mon, 4 Jan 2021 at 16:16, Rex Dieter rdieter@gmail.com wrote:
This is still largely accurate:
https://fedoraproject.org/wiki/SIGs/KDE/Update_policy
about the reasoning behind how and why.
Thank you very much for the link!
This text is different, in a way that is very important for me, from what I experienced a bit over a year ago on Fedora 29, which was then the previous-but-still-supported Fedora version.
The text says: "Users of previous Fedora releases need to understand that there will be no further updates to KDE during the life of this Fedora release. Exceptions will be for bug and security fixes that the KDE-SIG is able to backport."
I was on Fedora 29 back then, and my work was affected by https://bugzilla.redhat.com/show_bug.cgi?id=1746465 . This bug was triggered in August 2019 by a KDE Frameworks version update in Fedora 29, while Fedora 30 was released in April 2019.
I have checked, and the text is like this since 2014: https://fedoraproject.org/w/index.php?title=SIGs/KDE/Update_policy&diff=... . So apparently, and unfortunately for me, the policy does not seem to be followed.
Is there any chance that KDE SIG might adopt this policy and stop KDE package version updates for non-latest Fedora versions? This would really be a very happy change for me. I would want to help out with this as needed, but sadly my C++ abilities are rather limited (I'm a technical writer).
On Tue, 5 Jan 2021 at 16:04, Mikhail Ramendik mr@ramendik.ru wrote:
Is there any chance that KDE SIG might adopt this policy and stop KDE package version updates for non-latest Fedora versions?
To clarify, I mean stopping updating *upstream* package versions, with security/bigfixes backported on a best-effort basis - exactly as the wiki says.
Mikhail Ramendik wrote:
I was on Fedora 29 back then, and my work was affected by https://bugzilla.redhat.com/show_bug.cgi?id=1746465 . This bug was triggered in August 2019 by a KDE Frameworks version update in Fedora 29, while Fedora 30 was released in April 2019.
I have checked, and the text is like this since 2014:
https://fedoraproject.org/w/index.php?title=SIGs/KDE/Update_policy&diff=...
. So apparently, and unfortunately for me, the policy does not seem to be followed.
This policy is *only* (well *primarily*) about plasma releases, not frameworks. Frameworks are supposed to be always stable and generally not introduce experience-breaking changes.
-- Rex
On Thu, 2020-12-31 at 16:53 +0000, Mikhail Ramendik wrote:
Hello,
I would really like to understand the policy of the schedule of major KDE component version updates in Fedora.
I know of the Plasma release schedule problem. But this is bigger apparently. The bug that forced me to leave Fedora a year ago was https://bugzilla.redhat.com/show_bug.cgi?id=1746465 . This bug was caused by a version update of KDE Frameworks, affected usability, and took over a month to fix.
That is why I use F32 , instead F33 .
this is a very simplistic summary KDE is not scheduled with official release , we got some discussions about that, i.e. we are on our own. I use KDE since Fedora core 1 and the major problems was that we trust in upstream , when it say that is ready and sometimes it is not . Updates form kde 3 to 4 , and 4 to plasma 5 was a disaster but mainly because upstream calls it stable when it wasn’t.
Following this list, I see that breaking updates to KDE are kind of a regular occurrence: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/th...
I would guess that the component version updates mid-cycle cause the breaking updates. I would really appreciate some explanation of what the version update policy is.
Also is there *any way at all* to have a reliable KDE environment on Fedora, apart from not updating the entire system?
-- Yours, Mikhail Ramendik
Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
-
Alex Gurenko -
Gilboa Davara -
Matthew Miller -
Mikhail Ramendik -
Rex Dieter -
Sérgio Basto