Announcement

Collapse
No announcement yet.

KDE Plasma 6.0.1 Released With First Batch Of Bug Fixes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by sophisticles View Post
    As 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.
    You mean unlike closed source software, with Apple releasing borked iOS updates that cause bootloops? Or MS that releases updates that borks stuff, especially in the past two years that has happened multiple times. Or FOSS but from a big company like Google, that released a stable Chrome OS update that locked everyone out because they made a typo in the lock screen code?

    Comment


    • #42
      Originally posted by sophisticles View Post
      As 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.
      I wish Microsoft would just release Windows 11 when it's done, but they keep releasing monthly patches and security fixes all the time. I mean..really, what's up with those lazy SOBs? They're a billion dollar company..they should really do better. Oh..and don't get me started on Exchange or SQL server. Bug riddled messes. Constant patching. I really wish Microsoft hadn't released DOS back in the 80s and just waited until they were done.
      Last edited by rhavenn; 06 March 2024, 12:44 PM.

      Comment


      • #43
        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 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
        upstream mirror. Contribute to coreutils/coreutils development by creating an account on GitHub.

        Comment


        • #44
          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
          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**.
          That doesn't look like a bug fix to me, it's a workaround for something broken/loosely defined underneath. Again, utilities like "cat" haven't seen actual bug fixes in ages. Go check the same file.

          Comment


          • #45
            Originally posted by mirmirmir View Post
            So kde take one week for a minor release? Is it a new thing or always been like that?
            Yeah, that's how it works, but only for the first two point releases. Then it's a bit longer:

            Originally posted by community.kde.org
            Bugfix tags/releases are made on Tuesdays in a Fibonacci sequence of weeks (1, 1, 2, 3, 5)

            Comment


            • #46
              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!
              One minor correction with your statement, it should read:

              ??? 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


              • #47
                Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
                Your 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.

                So you are confirming that they have a lousy QC track record?

                Very nice of you.

                Comment


                • #48
                  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**.
                  That doesn't look like a bug fix to me, it's a workaround for something broken/loosely defined underneath. Again, utilities like "cat" haven't seen actual bug fixes in ages. Go check the same file.
                  I somewhat agree with you, but you're really stretching the argument. The many small individual utilities in CoreUtils - at the moment - could probably be considered "bug free." When you have files which have been hardened over multiple decades, in an environment where most software caters to them, you're going to get something 'stable.' But it doesn't mean they'll remain bug-free, it doesn't mean they're without issues, and it might be a case of developers working around an entrenched incumbent.​

                  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.

                  Comment


                  • #49
                    Originally posted by Nocifer View Post
                    Disregarding 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..?
                    This is my point exactly, they do not completely test their software and eliminate all the bugs and they, and their supporters, act like I have an arm growing out of my ass because i actually expect a programmer to test his software before releasing it.

                    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


                    • #50
                      Originally posted by sophisticles View Post
                      As 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.
                      Nothing would change, not even after a year of testing, because few people install a beta and report bugs, it is no coincidence that only after the official release reaches the general public there is a significant increase in bug reports, this happens for all software.
                      They have an automated internal QA system, but it doesn't cover everything, many bugs escape, for a thousand reasons.​

                      Comment

                      Working...
                      X