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.