https://bugs.kde.org/show_bug.cgi?id=470544
Nate Graham <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Resolution|--- |NOT A BUG Status|REPORTED |RESOLVED --- Comment #3 from Nate Graham <[email protected]> --- In a project with a deep technology stack, it's common that issues manifesting to users are caused by problems at a lower level in the stack. Other common examples that I can think of include: - Graphical glitches or multi-screen problems caused by graphics drivers - Audio issues caused by PulseAudio/PipeWire - Power management and battery life issues caused by the Linux kernel and its hardware platform drivers - Network connection isues caused by NetworkManager - Bluetooth connection issues caused Bluez etc. It would not feasible for KDE to take ownership of those parts of the stack by either forking them or assigning people to contribute to them; frankly we have trouble even maintaining our own code, due to its vast breadth and our limited resources. I wish this were different, but it's not. Ultimately, resolving issues like these is the job of the system integrators. Their role is to take diverse pieces of software, jam them together, see what breaks, assign people to work permanently on problem-child upstream projects, fix bugs in a targeted manner, QA the result and polish it up, and then distribute it as a cohesive supported product--likely for money, because doing all of this is un-fun work that people generally only do when paid. In the Linux world, historically our system integrators have been the software distributions--especially the ones that have commercial backing and deep pockets. Today the model seems like it's sort of dying, with the big players taking less interest in our world and neglecting critical issues for years, and a massive proliferation of micro-distros developed by 1-2 person teams that aren't sustainable and pass the buck for every issue below them. All of this makes sense when resources are highly constrained, as they are. It's my opinion that those selling Linux-powered hardware need to step up to take the role of system integrator more seriously, by putting dedicated engineering effort into fixing problems at all levels of the stack. When you get all the software you ship for free, that's a business cost savings, which should free up funds for developing it. This work takes money, and they have it. Certainly more than KDE and most distros do. Speaking personally, it's been my dream to see KDE itself become a hardware company and reinvest the revenue from selling devices into development not only on KDE software, but on the software we rely on. But at this point, it's just a dream. --- If you'd like to take the initiative to better-categorize the upstream bug reports that affect users so that there's at least a record of what's damaging the UX, that seems like something actionable that could be done--by anyone! Since you expressed interest in it, I think it makes sense for you to give it a shot. The way this would work is as follows: - Create a new metabug titled something like "Upstream libssh issues" - Find all the bug reports we have that are ultimately caused by upstream libssh issues - For each one, identify the upstream libssh bug report and put it in the URL field of the bug report, then close it as RESOLVED UPSTREAM and then mark it as a blocker for the metabug That way, even though they're closed in our bu tracker, the bug reports will still be findable. What do you think? -- You are receiving this mail because: You are watching all bug changes.
