On Fri, Nov 9, 2018 at 10:31 AM Lukas Ruzicka <lruzicka@xxxxxxxxxx> wrote:
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.
Requiring something without blocking doesn't make sense to me. You either need to block or kill the spin (neither of which I want to do), or it's not a requirement, it's a recommendation.
* 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.
I can't say I'm fond of a mandatory test case for non-blocking stuff. I'm often bad at choosing my fights, but testing non-blocking spins is definitely not my fight, and I'll rather spend my time on something else that is more important (read blocking) and/or currently on fire (there are always things on fire). That doesn't mean I don't report bugs for non-blocking apps and sometimes environments, I quite often do when I hit them during my day-to-day usage, but that's very different from a mandatory test case for that. Fedora provides a big playground for many different software projects, they can built stuff on top of Fedora, and it's up to their fanbase to make sure things are working. This is a perfect place for community to help out, if they regularly use these environments.
If this is an optional test case to help community focus on a few selected most important parts, i.e. guiding them where to best devote their time, sure (and we can think whether a test case is the best means to achieve that). Guiding people is always good and we don't do it very well. But that's a bit different story from what is proposed.
How does the community know what applications we do test and we would like them to test?
I partly covered that above. But honestly, I think "telling community what to test" will reach 1‰ of those reporting bugs, and it's not necessarily a problem and that they don't even need to care about it. It doesn't matter much what we test and what we don't. There are ton of bugs everywhere, you trip over them all the time. They are so many even in those primary deliverables, and countless in less visible environments and apps. When I started with Linux and OSS, I simply reported a bug every time I found something not working in those apps and environments I regularly used. That's the easiest thing the community can do to help QA, and they don't need to know or care about any test plans, test cases, release requirements or whatever.
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.
The point is, you bound together your core apps with higher quality standards. If you don't allow SIGs to include additional apps of their choice (e.g. gnome-boxes) to this higher quality bar ("this app must work great, or we don't want to release"), it's a bad proposal. That's why I said the two concepts should not be bound together, or the core apps definition should be strictly per spin and not universal.
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 you didn't mean it as it sounds, but just a note: bugs should be filed regardless of criteria or some other definitions. Criteria just decide when the bug is blocking (and that's when we "dictate to others").
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.
I wanted to say "sure it would make those spins better", but it largely depends on whether there any actual developers available to fix those bugs (in time). And I'm quite afraid about that for niche environments. That's why I prefer trying it first and make processes around it later. Otherwise it can happen you make architects create plans for a nice sky castle in your mind, only to find out later that there are no masons out there.
The second thing to consider is that you're always doing something at expense of something else. The new thing should either be more valuable, or a passion project.
Regarding the size of the community that could be influenced by a new optional test case in the matrix, I'm afraid that's quite small. I'd say an easy-to-read guide in "how can I help?" section on our wiki could be more visible.
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.
_______________________________________________ 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
