On Wed, Nov 7, 2018 at 4:40 PM Lukas Ruzicka <lruzicka@xxxxxxxxxx> wrote:
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?
OK. First of all, it might be confusing that you used the same term "core apps" for something that might be a bit different, even though I see the logic. It's currently used just in Workstation, you mean distro-wide. They are not specific apps, they are "app types". The Workstation spec has specific requirements for them, you have other requirements in mind. Unlike our current practice, you don't actually require them to be installed, it's just a recommendation for spins. So that's just to clear up terminology.
Now, my thoughts on the above:
* I don't feel in a position to decide which app types should fall into the category. That would probably be a FESCo decision.
* I'm not convinced that every spin needs to include app type X. Some DEs are highly different, like SoaS. If you include Labs in the mix, or whatever is present in comps, there could be (hypothetically) some highly specialized environments, like a tiling manager with cli-only tools, or whatever.
* Your definition seems to only think about graphical desktop environments, which goes against claim that this would be universal for all Fedora.
* The likely set of such core apps would probably be very small and very obvious, which means either those spins don't include it intentionally or it's a bug. In the first case, they won't change it, and the second case, they'll fix it if you report it. Either way, codifying it into a set of rules/recommendations seems to have little effect.
Overall it seems to me that if we just reported e.g. "hey, you seem to be missing a text editor in the main menu" to LXDE, it would solve the same problem without bureaucracy and definitions.
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.
And here's the overloaded term use. When you say "should go from core apps", are you forbidding Workstation SIG to define Boxes as their core app? I don't think you want to their their decision power over their own spin, but I'm trying to show how easily this can get misunderstood.
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.
OK, here's an important point. Up till now, I thought "cross-distro core apps" were just about being present. But now you're using it a base for defining additional functional criteria, e.g. that they need to work better than others. I don't think it's a good idea, because should it preclude Workstation SIG to include say Boxes in the mix? Either those two lists should be separate, i.e. here's a list A that contains all cross-distro core apps that must be present, and here's a list B that contains all Workstation SIG' approved apps that are subject to higher quality standards; or the cross-distro core apps concept should be ditched and every spin should define their own list of apps and then it would make sense to require the apps to be present *and* subject them to higher standards at the same time.
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?
The reasoning was that the rendering issue was happening just on certain system configurations. If it happened always, I hope it would get accepted as a blocker. It's very hard to define basic functionality unless you really go and list all basic operations for all apps present and spend your youth on it, and that's why it is a judgement call. And it seems obvious to me that more critical apps (like gnome-terminal compared to gnome-maps) would undergo stricter judgement. If you think this is not obvious, I'd be happy to approve amendment to that criterion saying that more critical apps are subject to stricter standards. At the same time I wouldn't want to lower the baseline. Even a completely unimportant app must work in basic scenarios, or it should be ditched from the compose.
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 imagine we could make a new criterion saying that core apps (defined by that particular WG, this is not what you proposed) must work well, i.e. all commonly used functionality must be bug-free (as opposed to just basic functions). That would increase the standards for them, but it would still be a judgement call in exactly the same manner, and I don't think we can go around that. And/or we can always defer to a particular SIG in such a contentious case and let them decide whether they want to release it like that or not, instead of making a group vote. (Historically though, we've mostly demanded higher standards than Workstation WG themselves, so this approach might not be pleasing for everybody. Just a side note.)
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.)
OK. But I think we can intuitively guess which apps are more important than others, or can't we?
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.
1. Use the "core apps" concept, but not cross-distro wide, but always specific to a particular Spin. The concept would mean "these apps must not be missing and are subject to higher quality standards [to be defined in a generic fashion and decided on a per-case basis as usual]". The SIGs would need to back this idea, i.e. have an interest in this increased quality checking *and blocking*. It might happen that no SIG would want that due to resource constraints.
(This would still need some fine-tuning, because we have something similar in Server, but already present as individual criteria.)
2. Any time we feel there's an important app missing in a non-blocking spin, just file a bug, no bureaucracy.
3. Amend basic functionality criterion to say that application importance affects the level of standard we have when judging the basic functionality it the impact on the users. All while not lowering the bar for non-important apps (even for those at least the basics must work).
_______________________________________________ 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
