> > 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". >
Yes, exactly. > 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. > No, not exactly. I require them to be installed and in the menus of graphical DEs, so that whoever chooses any of the suggested DEs (Anaconda offers them) should be able to start something with it without being too confused. > * I don't feel in a position to decide which app types should fall into > the category. That would probably be a FESCo decision. > We have never gotten so near, but true - if that has to be a distro-wide decisions, this should be a FESCo thing to decide. > * 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. > You are right, but except SoaS there is nothing called "working environment with DE", so I really do not require we check for everything. By the way, a tiling manager IS a graphical DE and if the core applications are all solved with CLI-tools ... I do not see any reason why not. > * Your definition seems to only think about graphical desktop > environments, which goes against claim that this would be universal for all > Fedora. > Yes, that is true. And maybe you have spotted a requirement to have such core applications for the Fedora server as well. In that requirement, the sender asked for preinstalled and preconfigured services ... and hey ... maybe it is not a bad thing at all (definitely a proposal for Server SIG). For sure, it is out of scope of our discussion. In a server environment, you always end up with CLI tools anyway, so I do not expect users get confused by that. > > 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. > > This is what my proposal is really about, Kamil. It seems to me that currently we do not file many bugs for non-blocking environments, we just let them go with the flow. Why? Because there isn't any required test case to test for them. Sure, we do not have time and resources to do it thoroughly, but we could at least test for "core applications" in those environments. How does the community know what applications we do test and we would like them to test? We will come up with a list, we revise it, perhaps get five applications (perhaps ten, I don't know) and we tell them. *We will make criteria for it*. So at least the minimum functionality will be tested and bugs filed. > 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. > > >> See the paragraph above, this is a huge misunderstanding here. For Workstation, we already test basic functionality for everything, not just those "core applications". If they want to have Boxes in Workstation, hell yeah. We will test it. But I do not see a point why an LXDE spin should care about virtualization in the basic package set. My logic is, that when I do not want to install Workstation because my computer is not capable running it, so it will not be capable running virtualization, either, and I definitely do not want services like libvirtd eating my memory. The "core applications" however must ensure that when a "first-time" user runs it, he will be able to find some apps to start with in the menus so that they could use the environment without having to go to terminal right away. > > 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. > Yes, the "core applications" I am talking about are not those that Workstation SIG have approved for Workstation. This is not about the Workstation, because it has everything it needs. This is about the other DEs. And yes, in that case, we would have two lists, one - type of applications that we would look for in all spins (in Workstation this is already covered, so there is no need to change anything). And the too quality approaches, when I say that an application should have "basic" functionality and I start "gnome-terminal" (just an example), it lets me do my CLI jobs just fine, but it will crash when I click on "Open new tab". Is it still basic functionality? Or is it some "enhanced functionality"? For a core application, this would have to work anytime. For just an application, this would be a matter of discussion on a blocker review meeting, for instance. > > 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). > This is exactly what I think I have proposed. My point is this: We are QA, which means that we care for better quality. We cannot dictate to anybody. But, if we are united in our stands, discuss what quality criteria we could use for it and start filing certain bugs according to those criteria, maybe the people in various spin SIGS will notice and do something about it. Maybe we can recommend things to them. Maybe they will hear us. Maybe not - but that's fine, we do not block on them. However, we could care for better quality even for those non-blocking stuff. > 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.) > The proposal was a part of the QA test list. So, the questions was ... do we, as QA, believe that a little bit increased activity with non-blocking spins can help make the Fedora feel better, or do we not believe in it. I do. But if it is just me, the only thing I can do is, as you are suggesting, keep testing it (when I have spare time) and keep filing bugs. And since you are the only one who actually responded to it, I guess it is exactly this case. > OK. But I think we can intuitively guess which apps are more important > than others, or can't we? > > We do. But do the community people, especially newbies, know it? I though that we wanted easy testing for community members. This might be one of them. -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
