> Kamil Paral wrote: > > I am opposed to this, as it is means Fedora is more likely to ship with > broken KDE applications. Even the core ones if the KDE Spin keeps also > shipping, e.g., Firefox (something I think should just stop, but that is not > my decision to make), since your proposal only requires ANY browser on the > Spin to work. I do not think it is acceptable to ship a Fedora KDE release > with a broken Falkon. Perhaps that could be an impetus to ship just one browser. The current situation is not just a poor situation for QA, it's also a poor situation for users. What I really wanted to avoid is to specify concrete application names on concrete desktops that need to be checked. That is a maintenance nightmare. That's why I suggested generic solution. The app duplication is not that common, it occurs mainly just on KDE. > > I also think that if we really want to limit the kinds of applications that > we block on, the same list should also apply to the GNOME-based Workstation. > I do not see why that should get preferential treatment over other release- > blocking Spins. Release-blocking is release-blocking. So you're OK with that change as long as no one else gets a better deal? Hmm. I've specified the reason. This is not about release-blocking status. Both Server and Workstation are release blocking, but e.g. broken ssh or remote logging would only block on Server and not on Workstation. We don't have universal rules across all release artifacts. This is about Workstation being a flagship product, an Edition, an artifact that gets offered on the very home page of getfedora.org. As such, we can have extra requirements for it. KDE is a Spin, a lower visibility artifact. You might be salty about that, but I'm just stating the facts, this is not an attack on the quality or usefulness of KDE itself. Don't get me wrong, I'd love to have all images that we produce to have a top-notch quality. But our team has a fixed size, the number of important products keeps growing, we don't see much external involvement in release validation efforts, and we need to resolve it somehow. Out of curiosity, would you be willing to contribute in release validation testing and cover the apps which are not part of the proposal, in order to keep the "all apps must work" criterion for the KDE spin? I'm not sure it is the right solution, but I'm interested in hearing your thoughts. _______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
