Re: New releases for bugfixes
On Sat, Sep 10, 2022 at 5:41 AM Reindl Harald wrote: > > > > Am 09.09.22 um 11:42 schrieb samuel ammonius: > > Thanks. I hadn't thought of a lot of these issues before. > > > > I think the biggest one is that If there's an update that the package > > manager didn'tknow about, the user would have to update right after > > installing, and > > the bug would come back if the user re-installed or updated the app. Sorry > > everybody > no the biggest issue on the userside is that nobody wants every random > application tamper the system > > if i want applications asking me about updates i could have stayed at > windows and "yum upgrade" was the main reason for Linux > > when you open that can of worms imagine where it ends > > security wise it's a nightmare because you not only have the > distribution you need to trust - intrusion on any upstream would > directly hit you at any random point in time while distribution updates > are usually tested at least by some people and changes reviewed by > downstream maintainers > > and who does the work and deal with bugreports "the update of kate > destroyed it on my system and i don't know why nor how i revert it" > > with the package manager i type "dnf downgrade kate", file a bug against > the distribution and kde upstream isn't involved at all > > upstream opensource developers write the code, that's it, they don't and > shouldn't need to care about every downstream distribution and it's > pitfalls - it's wasted time because that's what downstream component > maintainers are for > > the fedora maintainer from kde likely has no knowledge about Gentoo, > Ubuntu, SuSE for good reasons and you think blow that load to upstream > developers would help anybody? > Well, actually, most of us do know each other and we do collaborate from time to time. I personally know Fabian Vogt (the maintainer of the KDE stack in SUSE distributions) and I talk to Rik Mills (the Kubuntu maintainer) every once in a while. Same goes for Mageia, OpenMandriva, Debian, and others. Admittedly, I don't know who works on KDE Plasma for Gentoo, but I'm peripherally aware of their work. As maintainers of KDE software in our respective distributions, it's our job to bring our concerns upstream as needed. But also, when distributions have a conflict, we *all* have to work together to figure out a solution. If we don't, we risk a situation where KDE eventually evolves into other similarly-sized desktop environment projects where they give the downstream stakeholders the finger because they don't trust them. Also, many of the upstream KDE Plasma developers are in fact distro developers. It's not the majority anymore like it was in the old days, but a good chunk of them are. -- 真実はいつも一つ！/ Always, there's only one truth!
Tips in splash screen on startup (suggestion)
Hello everyone, KDE has a lot of features that most people don't know about, so what if a tip was shown on the splash screen during each startup? For example, the first startup could show: > Tip #1: You can open a terminal inside Dolphin using CTRL+SHIFT+F4 at the bottom of the screen. Then the next could show > Tip #2: You can manage your Google Drive by adding an online account in the settings (I'm just using these examples to show what I mean by "features that most people don't know about". There's definitely a ton of these, so if the developers of different projects added a few tips to the list, these features could be used by more people) There could be a setting to configure them to: 1. Numerical order 2. Random 3. Hidden / Disabled Thoughts? Sam
Re: Product organization in Bugzilla
Am Freitag, 16. September 2022, 14:05:36 CEST schrieb Nicolas Fella: > you are on to something that I wanted to raise anyway: Quite often > people report bugs for a frameworks they think is related to the problem > instead of the product we expect them to use. Some examples: To me these examples look like a systematic problem in KDE components rather than the users fault. I don't think a user can be expected to know the component in any of these cases. For applications, the Help | Report bugs action at least leads to a good starting point and makes sure that the bug is seen by some person who can further triage it into the proper component. Is it really not possible to get a similar (if not better) user experience for the more integrated components of the desktop stack? Suppose I experience a problem with, say, the clock widget: I can right click on it and even get a settings dialog for it. But clicking on the "about" tab I get the localized widget name and a link to kde.org/plasma-desktop. Why does the user have to find bugs.kde.org on their own, find that "plasma-desktop" is not actually a component in bugzilla, but that they need to file their bug in plasmashell and then reverse translate the component name to file the bug? To end my rant on a productive note: Yes, sure - hide internal components as you see fit (maybe hide archived/unmaintained components as well, while you're at it). But IMO the main problem is that users have to search on bugzilla instead of clicking a link inside the actual software component that they use. Cheers, Johannes
Re: Product organization in Bugzilla
On 9/19/22 15:33, Johannes Zarl-Zierl wrote: To end my rant on a productive note: Yes, sure - hide internal components as you see fit (maybe hide archived/unmaintained components as well, while you're at it). But IMO the main problem is that users have to search on bugzilla instead of clicking a link inside the actual software component that they use. Exactly. See https://bugs.kde.org/show_bug.cgi?id=370195 and https://bugs.kde.org/show_bug.cgi?id=204364. That said, I don't expect implementing these features to fully resolve the issue, though I agree with you that it would help a lot. Nate
