Originally posted by sophisticles
View Post
Announcement
Collapse
No announcement yet.
KDE Plasma 6.0.1 Released With First Batch Of Bug Fixes
Collapse
X
-
- Likes 10
-
Originally posted by sophisticles View PostAs i said in the other thread, I have no plans to try this release, at least for a while.
This DE was just released and they already found bugs significant enough to warrant a updated version.
This is what i keep talking about with open source software, why do these projects not completely test their software and eliminate all the bugs before they release it.
It would look much more professional if they waited a week and released their "KDE MegaRelease 6" with no bugs to fix.
As it stands now, I fully expect to see another such article in a week or so about bug fixes.
These open source projects really need to get their QA in order.Last edited by rhavenn; 06 March 2024, 12:44 PM.
- Likes 8
Comment
-
Originally posted by avis View Post
Which utils got fixes though? It's so easy to be nitpicky and "prove" your particular point of view while dismissing the opposing PoV. Have you actually checked the fixes? What if they are not bug fixes, but planned changes in behavior? Or improvements because some new data became available but they worked in the past just fine but not with something which has become available just recently? Fixes can be quite different in their scope.
Again, bug free software does exist and it's not rare.
I'm also quite sure that it wouldn't be enough to change your mind...
By the way, you can look for bugs fixed in coreutils under ** Bug fixes
- Likes 3
Comment
-
Originally posted by JackLilhammers View Post
I'm quite certain that most software developers would tell you that bug free software is extremely rare.
I'm also quite sure that it wouldn't be enough to change your mind...
By the way, you can look for bugs fixed in coreutils under ** Bug fixes
https://github.com/coreutils/coreutils/blob/master/NEWS
Code:cp, mv, and install no longer issue spurious diagnostics like "failed to preserve ownership" when copying to GNU/Linux CIFS file systems. They do this by **working around some Linux CIFS bugs**.
- Likes 1
Comment
-
Originally posted by mirmirmir View PostSo kde take one week for a minor release? Is it a new thing or always been like that?
Originally posted by community.kde.orgBugfix tags/releases are made on Tuesdays in a Fibonacci sequence of weeks (1, 1, 2, 3, 5)
- Likes 2
Comment
-
Originally posted by zexelon View Post??? This is actually doing 90% better then most software out there... they released a new minor version with a number of fixes a FULL WEEK after the major release!! Most software these days needs at least a massive multi-gb day zero patch just to not crash on first run!
??? This is actually doing 90% better then most open source software out there... they released a new minor version with a number of fixes a FULL WEEK after the major release!! Most open source software these days needs at least a massive multi-gb day zero patch just to not crash on first run!
There you go, now they can upvote you.
Comment
-
Originally posted by pWe00Iri3e7Z9lHOX2Qx View PostYour post has zero merit and calls into question whether you even have basic familiarity with KDE. This is the normal point release schedule for the project. X.1 comes out one week after X.0. X.2 comes out one week after X.1. X.3 comes out two weeks after X.2. This isn't hard to verify, and it's not new.
Very nice of you.
Comment
-
Originally posted by avis View Post
The very first fix in the document:
Code:cp, mv, and install no longer issue spurious diagnostics like "failed to preserve ownership" when copying to GNU/Linux CIFS file systems. They do this by **working around some Linux CIFS bugs**.
There's a shocking amount of "bug free" software when examined in a vacuum. It's very possible to have multiple pieces of software which work as intended separately, but the moment you put them together things break. Everything is on a stack and you don't really get to isolate yourself from the environment you're in. A huge number of bugs and flaws have more to do with unanticipated software interactions, rather than outright mistakes. You can't argue that a piece of software is totally bug free and ignore the stack it's built around.
Going by that logic you could almost argue that KWin is bug free - as long as you ignore bad graphics drivers, misbehaving applications, Qt issues, and hardware misreporting capabilities. CoreUtils has a lot of fixes, like the MV command that was broken by ZFS. You might say ZFS had the bug. You might claim Core had the bug. But there was a bug. How do you determine whose at fault? Is whoever came first? Whoever is "lower" on the stack? Whoever has more users? Going back to the KWin example, Electron regularly crashed KWin back in the day because it often spammed data. By every metric it was Electrons' fault, but because only KWin was affected the L went to KDE. It wasn't even a bug per-se, but a soft-spot that was hit unusually hard.
Ultimately what it comes down to is the fact that even simple utilities hook into complex systems which do the heavy lifting. Those simple utilities even if they're decades old and battle-hardened don't anticipate everything. Bugs can impact anything up and down the stack, and the simple fact is trying to claim any piece of software is bug-free is a semantic argument over who gets the blame.
About the one strong argument you could make is that some utility software is so entrenched it becomes "bug free by fiat" because any changes to it risk breaking too many other users of the stack. If cat is messing up somewhere under certain circumstances, are you going to risk breaking 3 major kernel families, dozens of filesystems, thousands of applications, tens-of-thousands of scripts, and deal with billion-dollar companies who will demand every change be tested into the ground - or are you going to work around it? You're going to work around it.
- Likes 6
Comment
-
Originally posted by Nocifer View PostDisregarding the fact that the KDE 6 release has actually gone very, very smoothly (weird packaging issues in Neon notwithstanding), open source projects do not "completely test their software and eliminate all the bugs" because, unlike big corporations with big money, they do not have huge QA teams who get paid during the development cycle to do the testing for them (and usually fail miserably at their jobs, but that's another story); so what they can do, is release the software when it's more or less ready and then rely on their end users to actually use it and report bugs and issues for the final polishing. This is how it's always been done in open source. Perhaps you're new here..?
As for KDE not having a huge QA team, did you see the picture the posted of the team? there has to be at least 50 people each of which has at least one computer and are presumably using the software.
They can't find all the bugs after all this development time?
You also touched on the biggest issue related to open source, namely that the end users are the guinea pigs, the open source community seems to have no problem with perpetually beta software.
I hope the COSMIC people don't embrace the same attitude.
Comment
-
Originally posted by sophisticles View PostAs i said in the other thread, I have no plans to try this release, at least for a while.
This DE was just released and they already found bugs significant enough to warrant a updated version.
This is what i keep talking about with open source software, why do these projects not completely test their software and eliminate all the bugs before they release it.
It would look much more professional if they waited a week and released their "KDE MegaRelease 6" with no bugs to fix.
As it stands now, I fully expect to see another such article in a week or so about bug fixes.
These open source projects really need to get their QA in order.
They have an automated internal QA system, but it doesn't cover everything, many bugs escape, for a thousand reasons.
- Likes 2
Comment
Comment