Actually, this might be a misunderstanding. The testcase is called *Workstation* core apps, and the technical specification wiki is in the *Workstation* namespace. The Workstation SIG have defined their core apps, and we have a test case for them. There are no other core apps. So sure, workstation core apps are tested on workstation images, and nowhere else, because that wouldn't make sense :)
By core apps, I am not talking about Firefox, gnome-terminal, and such. I am talking about terminal emulator, web browser ...
On the contrary, core apps make a lot sense for all spins. I do not see why there should be a spin made without a terminal, for instance. It does not have to be gnome-terminal, but some emulator should be present. The same goes for other apps that I believe are at core of a computer system, therefore I call them CORE applications.
[trimmed]
core apps, we can define KDE core apps, XFCE core apps, Server core apps (which we somewhat already have, just in a different structure, in our existing criteria), ...
We will probably just block on what we block now, but it could be a nice signal to the spin groups that something like that is "a nice to have". If they do not want to follow it, we will not be able to do anything about it, but I see it as a logical thing. If, for example, there is no text editor in LXDE, the user experience is somehow limited. And as far as I know, Fedora promotes some of the spins as suitable for older laptops. Sure, but why not to push for some better quality of that spins, although we do not block on that?
Workstation WG will want to have virtualization front-end, while KDE won't. Text-only spins won't want to a web browser. Etc.
Virtualization frontend should go from core apps, IMHO. At least according to what I believe is a core app. If it is in the spin itself, ok. But this is nothing that would be needed by everyone and a crucial part of the system.
I don't understand which apps and which functionality you talk about here. We already require basic functionality for all default desktop apps, and our criteria include required functionality in many tools/apps outside of the basic scope. What do you mean here?
I believe that OS is a good OS, when you can do something with it. There are some minimal tasks that it should be able to do for you. For example, it has to let you install packages. On the other hand, it does not have show you a route from one place to another. What I am trying to say here is, that for those core applications, we should probably focus more on the functionality than just basic functionality and for the rest we might be more tolerant.
Example, during the blocker review meeting, we were discussing if Maps had a blocker bug, finally the WG decided that it was not a blocker bug. I agree it was not. But ... If gnome-terminal had a similar rendering issue ... would that be a blocker? why or why not? If this was among the core application, I would say that it would be definitely a blocker to me. So basically, I am suggesting to make the situation a little less messy and the guidelines a little clearer.
I'm missing one thing and perhaps I misunderstood some of this because of that. What is your main motivation here? What exactly are you trying to improve? Thanks.
My motivation is:
- realize what is really important that we test -> let's discuss that
- if we realize, that there is something "not as important" -> test for the basics and not spend time too much on such things - who is really interested about the functionality of ABRT reporter?
- if we realize that there is something "very important" -> think how to test it more thoroughly (I believe those core apps are a good example of apps that should be tested thoroughly.)
Therefore, I wanted to start the discussion. If you think, that we do not need any improvement here, it is a valid opinion. Perhaps, it's just me who supposes that we could improve the routines a little bit. If so, I gladly give up on trying and we'll be good as gold.
--
Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
