Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Kamil Paral]

On Sat, Nov 10, 2018 at 11:14 AM pmkel...@frontier.com <
pmkel...@frontier.com> wrote:

>
> > I'd say an
> > easy-to-read guide in "how can I help?" section on our wiki could be more
> > visible.
> >
>
> As one of the newbies (joined in March 2018) I will wholeheartedly say
> Great Idea! I'm still trying to figure this out. The only things the
> wiki seems to point to are testing updates and running the standard test
> cases. I certainly understand these are both important, but Coconut is
> running most of the tests these days leaving apparently little a for a
> human to do.


I need to highlight something here. It's the very opposite. OpenQA
(coconut) does very *little* testing actually, just the basics. It is a
large portion of our test matrices, that's correct, but it's just a tiny
bit of all the combinations and installation+system workflows you can
perform. Following the test cases is of course helpful, but the most
beneficial thing you can do is just to play with the installer/system,
explore, try whether this or that works. That has a much better chance of
finding bugs than those beaten paths in the test cases. Test cases are just
for the basics, because we can't defined a million test cases for every
possible button click. There are so many things out there that can be
tested.

Every time you find a bug, please report it, propose it as a blocker if it
is very severe, or perhaps discuss it or notify us on the test list. If
there isn't a test case for it and a wiki box to fill out, that doesn't
matter at all.

We probably do a very bad job communicating this :/
___
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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[pmkel...@frontier.com]

I'd say an
easy-to-read guide in "how can I help?" section on our wiki could be more
visible.



As one of the newbies (joined in March 2018) I will wholeheartedly say 
Great Idea! I'm still trying to figure this out. The only things the 
wiki seems to point to are testing updates and running the standard test 
cases. I certainly understand these are both important, but Coconut is 
running most of the tests these days leaving apparently little a for a 
human to do. For testing the updates it seems like you have to be one of 
the old hands to even know what an update item is and what it dose. When 
I read the information on a candidate in bodi and with the package in 
many cases these questions don't seem to be answered. It seems quite a 
rare occasion when I know or can figure out what a candidate is so I can 
go ahead and do some rational testing.




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.



I don't mind having to figure things out and make up my own test plan 
when there is some information available I can base that on. However 
figuring out what is most important needs knowledge of the system 
architecture, data flow, etc. For instance, a primmer on d-bus and other 
data / control vehicles would be very helpful. Alternatively a 
prioritized list of the "important things" with a brief what it is and 
what it does. would be useful.


I've also come to understand that much of the information I look for is 
available, but finding it can be a real challenge.


Not all of the newbies are software / IT students or new graduates. I'm 
a retired EE that's also written my share of software. Though I've not 
been inside an OS before. I want to help because I really like Fedora.


I know I've suggested a lot of apparently new documentation that isn't 
likely to appear anytime soon for lack of volunteer hours. I also 
understand it my have limited value if there are enough volunteers that 
already know these things. With these points in mind, I'll just keep 
going the way I have been.



Have a Great Day!

Pat (tablepc)



___
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


___
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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Kamil Paral]

On Fri, Nov 9, 2018 at 10:31 AM Lukas Ruzicka  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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Firas Dieter Nuwayhid]

I think you have good core ideas (haha, the "core" word again:)), but the whole 
proposal seems a bit overkill. I'd personally suggest:
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).
I completely agree on these points with Kamil. I would just extend the first 
point by one thought/idea that Lukas already brought up:

We should increase the detail level of the specifications for the core apps. 
Instead of listing what apps should be used, we should additionally specify 
what tasks need to be handled by these apps. Based on this specification we can 
write proper test cases that actually have a bi-directional-traceability (and 
therefore are based on a common source, the specification).

On Fri, Nov 9, 2018 at 5:43 PM, Gavin Flower  
wrote:

On 10/11/2018 05:09, pmkel...@frontier.com wrote: 
[...]
I think for just the Workstation testing I do myself I will continue with my 
"over testing" approach where I "try out" all of the graphical app's that 
anaconda installs. and file bugs (not nominated) for issues I fine.
That's wonderful!
I also see the point that the non-Gnome spins could benefit from some more 
testing and will start doing testing with one or two of them. Any suggestions 
on which spins could benefit most from some attention?
Mate of course!  Although, I admit I'm biased here... But more sensibly, I 
don't have sufficient knowledge to answer your question properly. [...] Cheers, 
Gavin ___ test mailing list -- 
test@lists.fedoraproject.org To 
unsubscribe send an email to 
test-le...@lists.fedoraproject.org 
Fedora Code of Conduct: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetfedora.org%2Fcode-of-conduct.html&data=02%7C01%7C%7C4ded8d05283a43fecfe808d646629497%7C84df9e7fe9f640afb435%7C1%7C0%7C636773786545211553&sdata=EaLDQ8YR%2BmpZltaiATcjENIFAui%2BmJKzPuswxvoysBU%3D&reserved=0
 List Guidelines: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7C%7C4ded8d05283a43fecfe808d646629497%7C84df9e7fe9f640afb435%7C1%7C0%7C636773786545211553&sdata=Axj9nV0oxK7bi%2BCc9t0rLza65UX3MURAqgniY%2BW8Hlw%3D&reserved=0
 List Archives: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Ftest%40lists.fedoraproject.org&data=02%7C01%7C%7C4ded8d05283a43fecfe808d646629497%7C84df9e7fe9f640afb435%7C1%7C0%7C636773786545211553&sdata=Rtmjj9Nq7OfKWdSrpuvlNhLX5%2BZhNBMULrq1I3TPmYs%3D&reserved=0
___
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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Gavin Flower]

On 10/11/2018 05:09, pmkel...@frontier.com wrote:
[...]


I think for just the Workstation testing I do myself I will continue 
with my "over testing" approach where I "try out" all of the graphical 
app's that anaconda installs. and file bugs (not nominated) for issues 
I fine.


That's wonderful!




I also see the point that the non-Gnome spins could benefit from some 
more testing and will start doing testing with one or two of them. Any 
suggestions on which spins could benefit most from some attention?


Mate of course!  Although, I admit I'm biased here...

But more sensibly, I don't have sufficient knowledge to answer your 
question properly.


[...]


Cheers,
Gavin
___
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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[pmkel...@frontier.com]

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.



Thank you. I have been following this discussion and as a new kid in QA 
I have learned that this issue that I originally thought was straight 
forward is very complex.


I think for just the Workstation testing I do myself I will continue 
with my "over testing" approach where I "try out" all of the graphical 
app's that anaconda installs. and file bugs (not nominated) for issues I 
fine.


I also see the point that the non-Gnome spins could benefit from some 
more testing and will start doing testing with one or two of them. Any 
suggestions on which spins could benefit most from some attention?



Have a Great Day!

Pat (tablepc)


___
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


___
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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Lukas Ruzicka]

>
> 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 cove

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Kamil Paral]

On Wed, Nov 7, 2018 at 4:40 PM Lukas Ruzicka  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
th

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Firas Dieter Nuwayhid]

Hello Lukas,

I think it is great that you started this discussion. It really made me think 
for a while.

In general: I think it is a good idea to make test cases high-level so that 
they require less maintenance and offer more flexible testing.

I still don't think that changes are required, because:


  1.  Workstation in Fedora is automatically referring to the gnome desktop 
environment. Other environments are called ' Desktop'.
  2.  The links that you provided are the technical specifications for the 
Fedora Workstation. While test-cases should be high-level, specifications 
should be precise and specific. And because Fedora Workstation is a Gnome 
environment, it is natural to exactly specify what package is the core app for 
a specific service. Coming from a company that deals with medical devices I 
think reducing detail level of the specification would not improve anything.
  3.  A basic principle of quality: it is not possible to achieve a high level 
on all 6 quality characteristics. Starting to spend resources on every desktop 
environment dilutes the quality of the core product. Even though I prefer XFCE, 
Fedora Workstation is a gnome environment and this should have all the focus. 
(I am not saying that we should ignore the spins, embrace them and help the 
community, but stay on the core path!)

I would really appreciate your thoughts on my points Lukas.

Kind regards
Firas D. Nuwayhid (nomos)

From: Lukas Ruzicka 
Sent: Wednesday, November 7, 2018 4:38 PM
To: For testing and quality assurance of Fedora releases
Subject: Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

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? Wh

Re: Fwd: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Lukas Ruzicka]

Hello Gavin,

I, myself, am a user of an alternative desktop (Fluxbox and Qtile) and I
agree with you that others would deserve more attention, too, however I do
not think that we have so much testing power to cover more desktops
thoroughly. And, if we did, that other desktops have so much development
power to deal with reported bugs.

My point was, that there are some Fedora spins (LXDE, LXQT, and so on)
which are installable with Anaconda and promoted in descriptions as
Lightweight alternatives to Gnome Desktop and KDE, but at the same time,
they lack basic functionality. If for example, a text editor or a terminal
emulator is not accessible from the main menu. Then, users who install this
spin, based on the Anaconda description, will get a terrible user
experience. If they stick with one the main DE, such as Gnome, KDE, XFCE or
Mate, their experience might be different.
What  I am trying to achieve, is we would at least try to get a set of core
applications to all such spins (or package sets) and make sure, these apps
are listed in the menus.

Thank you very much for your view.

Lukas



> I agree.
>
> I used to use GNOME 2 exclusively (I think GNOME 2.4.2 was probably the
> best version), but am now in mate, after going initially to xfce,
> because GNOME 3 laced customisability, functionality, and is simply too
> hard to use.  The arrival of GNOME 3 drove a lot of people into
> alternative Desktop Environments, so GNOME is no longer as popular as it
> once was.
>
> I suspect that a lot GNOME 3 usage hinges on the fact that it is the
> default option, and people have to make an explicit choice to select a
> different DE.
>
> Mate, and at least one other DE, have a lot of stuff in common with GNOME.
>
> However, even where the DE has little in common with GNOME, it may
> deserve more support.
>
> Essentially one of the benefits of Linux over Apple's and Microsoft's
> offerings, is that users have a choice of Desktop Environment.  So it
> would be good for Fedora, if a wider range of DE's are more fully
> supported.
>
>
> Cheers,
> Gavin
>
>
>

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO 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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Lukas Ruzicka]

Hello Firas,
I agree with you in the points you are suggesting. However, I might have
made a mistake to link to that Workstation specifications, because now it
looks like I want to change the core applications for the Workstation. On
the contrary.
I would like to take those Workstation core applications as specimen of
possible core applications (in my understanding, these should be apps that
are thoroughly tested and that solve a very basic and important use of an
operating system.) I am also totally fine with Gnome applications that are
currently used for it.
What I am not very satisfied with the following points:

   - For Gnome Workstation, all applications are tested and require basic
   functionality, however we do not define exactly what basic functionality
   is. Therefore, the results might vary from a person to person. Also, I
   believe that the core applications should be tested more than just for
   basic functionality, if basic functionality means that they start and do
   something.
   - There are spins, where not all of the core applications (mentioned in
   the list for GW) are present in the spin. Here, I do not think about
   particular Gnome equivalents, but there was a spin where I could not find a
   terminal emulator. At least, it was not part of the menu. For less advanced
   users, this could be frustrating. So, I would like that all spins would
   have their own equivalents of core applications and we would check that
   they are in the menus and that they start. I understand, that we will not
   block on them, but it would increase the usability of the spins with
   minimum effort.

I totally agree, that the main focus should stay on the core of Fedora,
which is Gnome Workstation. If we stopped blocking on the whole KDE and
just checked for the core applications, we would win the time to check for
core applications on every spin.

Thank you for your views.

Lukas


>
>1. Workstation in Fedora is automatically referring to the gnome
>desktop environment. Other environments are called ' Desktop'.
>2. The links that you provided are the technical specifications for
>the Fedora Workstation. While test-cases should be high-level,
>specifications should be precise and specific. And because Fedora
>Workstation is a Gnome environment, it is natural to exactly specify what
>package is the core app for a specific service. Coming from a company that
>deals with medical devices I think reducing detail level of the
>specification would not improve anything.
>3. A basic principle of quality: it is not possible to achieve a high
>level on all 6 quality characteristics. Starting to spend resources on
>every desktop environment dilutes the quality of the core product. Even
>though I prefer XFCE, Fedora Workstation is a gnome environment and this
>should have all the focus. (I am not saying that we should ignore the
>spins, embrace them and help the community, but stay on the core path!)
>
> I would really appreciate your thoughts on my points Lukas.
>
> Kind regards
> Firas D. Nuwayhid (nomos)
> --
> *From:* Lukas Ruzicka 
> *Sent:* Wednesday, November 7, 2018 4:38 PM
> *To:* For testing and quality assurance of Fedora releases
> *Subject:* Re: [fedora-qa] Issue #569: Proposal to redefine core
> applications.
>
>
>
> *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 experi

Re: Fwd: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Gavin Flower]

On 07/11/2018 23:33, Lukas Ruzicka wrote:

Hello Fedora QA and friends,

I would like to propose a change of what we define as core 
applications because I feel that how it is done today is not 
sufficient. Let me explain.


## How it works today?

The *core applications* are defined in this testcase 
(https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications). 
In our matrices, the core applications are only tested for Gnome 
Workstation. The appropriate test case 
(https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications) 
requires that all core applications are installed on the system and 
that they start. The functionality is apparently tested by the 
*Desktop Menus Testcase*.


## How I think it could work?
I think we could change how we approach the core applications, how we 
test them and where we test them. For example:


* A list of generic core applications should be made (or the old list 
used, see above), so that core applications are not limited to a 
certain desktop environment (although we only test Gnome). By 
*generic* I mean that we should not explicitly say, if the terminal 
application is *gnome-terminal* or anything else. We only say it is a 
*terminal* application and each spin will pick up what suits best for 
them.
* Core applications should be promoted to be a part of all Fedora 
spins. It should not happen that a spin is missing a core application 
after a clean installation.
* The presence check (that the apps are installed) could be easily 
done by OpenQA. Possibly, it could be done even for more DE than just 
Gnome, hence we could enhance the user experience for spin users.
* Functionality of the applications should be redefined - what we 
expect for them to be doing - and this functionality should be 
required. I suppose, that we would only block on Workstation 
functionality, though. However, these guidelines could help the spin 
teams to decide which apps to use as core apps.
* *Core applications* should not just have a basic functionality, as 
defined in *Gnome Menus testcase* 
(https://fedoraproject.org/wiki/QA:Testcase_desktop_menus), they 
should be fully functioning.


Before I focus on details, I would like to know your opinions on this 
matter.


Thank you.

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-qa/issue/569


I agree.

I used to use GNOME 2 exclusively (I think GNOME 2.4.2 was probably the 
best version), but am now in mate, after going initially to xfce, 
because GNOME 3 laced customisability, functionality, and is simply too 
hard to use.  The arrival of GNOME 3 drove a lot of people into 
alternative Desktop Environments, so GNOME is no longer as popular as it 
once was.


I suspect that a lot GNOME 3 usage hinges on the fact that it is the 
default option, and people have to make an explicit choice to select a 
different DE.


Mate, and at least one other DE, have a lot of stuff in common with GNOME.

However, even where the DE has little in common with GNOME, it may 
deserve more support.


Essentially one of the benefits of Linux over Apple's and Microsoft's 
offerings, is that users have a choice of Desktop Environment.  So it 
would be good for Fedora, if a wider range of DE's are more fully supported.



Cheers,
Gavin

___
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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Lukas Ruzicka]

>
>
> *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

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO 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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Kamil Paral]

On Wed, Nov 7, 2018 at 11:35 AM Lukas Ruzicka  wrote:

> Hello Fedora QA and friends,
>
> I would like to propose a change of what we define as core applications
> because I feel that how it is done today is not sufficient. Let me explain.
>
> ## How it works today?
>
> The *core applications* are defined in this testcase (
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications).
>
>

The correct link to the test case:
https://fedoraproject.org/wiki/QA:Testcase_workstation_core_applications


> In our matrices, the core applications are only tested for Gnome
> Workstation.
>

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 :)


> The appropriate test case (
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications)
> requires that all core applications are installed on the system and that
> they start. The functionality is apparently tested by the *Desktop Menus
> Testcase*.
>

I think we should adjust the test case and ask the tester to verify that
the apps are present. Because that's the idea behind it, core apps must be
present (i.e. they must not fall out of the image by accident). Their
startup and functionality is tested by another test case [1], that's
correct, so it's an unneeded duplication to also require it in this test
case. Once the test case is redefined to only check for presence (say rpm
and a desktop icon), it can then be easily automated.

[1] https://fedoraproject.org/wiki/QA:Testcase_desktop_menus


>
> ## How I think it could work?
> I think we could change how we approach the core applications, how we test
> them and where we test them. For example:
>
> * A list of generic core applications should be made (or the old list
> used, see above), so that core applications are not limited to a certain
> desktop environment (although we only test Gnome). By *generic* I mean that
> we should not explicitly say, if the terminal application is
> *gnome-terminal* or anything else. We only say it is a *terminal*
> application and each spin will pick up what suits best for them.
>

Well, the test cases mostly match release criteria, the release criteria
only apply to blocking images, and blocking *desktop* images contain GNOME
and KDE on x86_64 and XFCE on arm. So even if the test case says "The
environment MUST contain a terminal, a web browser and a text editor", what
does the MUST mean for e.g. LXDE? Nothing really. Also, I expect the
intersection of core apps across various environments to be quite small
(terminal, web browser, text editor, file manager) and pretty much obvious.
If you include Server and Cloud in the mix (and they should not be left
behind, if these are generic requirements), the intersection might be
empty. So instead of generic requirements, per-SIG requirements might be a
better fit. We already have Workstation 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), ...


> * Core applications should be promoted to be a part of all Fedora spins.
> It should not happen that a spin is missing a core application after a
> clean installation.
>

Workstation WG will want to have virtualization front-end, while KDE won't.
Text-only spins won't want to a web browser. Etc.


> * The presence check (that the apps are installed) could be easily done by
> OpenQA. Possibly, it could be done even for more DE than just Gnome, hence
> we could enhance the user experience for spin users.
>

Agreed.


> * Functionality of the applications should be redefined - what we expect
> for them to be doing - and this functionality should be required. I
> suppose, that we would only block on Workstation functionality, though.
> However, these guidelines could help the spin teams to decide which apps to
> use as core apps.
>

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?


> * *Core applications* should not just have a basic functionality, as
> defined in *Gnome Menus testcase* (
> https://fedoraproject.org/wiki/QA:Testcase_desktop_menus), they should be
> fully functioning.
>

What does fully functioning mean? A slippery slope here :-) Either way,
this needs to get developer backing, and I'm very skeptical about getting
it.


>
> Before I focus on details, I would like to know your opinions on this
> matter.
>

I'm missing one thing and perhaps I misunderstood some of this because of

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Lukas Ruzicka]

Yes,
we could discuss that also, but I would like to keep the threads separated
if possible.

Lukas

On Wed, Nov 7, 2018 at 11:44 AM Julen Landa Alustiza 
wrote:

> Related to this and server, and remembering that we had a non working cron
> issue proposed as blocker but we didn't have a clear criteria that was
> violated to accept the blocker bug, but the majority of the meeting
> attendees was in favour of blocking because cron was not working on server
> edition and that was a big issue... could we discuss about having blocking
> core applications on server flavour? just some basic services, sshd, cron,
> systemd...
>
> El mié., 7 nov. 2018 11:35, Lukas Ruzicka  escribió:
>
>> Hello Fedora QA and friends,
>>
>> I would like to propose a change of what we define as core applications
>> because I feel that how it is done today is not sufficient. Let me explain.
>>
>> ## How it works today?
>>
>> The *core applications* are defined in this testcase (
>> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications).
>> In our matrices, the core applications are only tested for Gnome
>> Workstation. The appropriate test case (
>> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications)
>> requires that all core applications are installed on the system and that
>> they start. The functionality is apparently tested by the *Desktop Menus
>> Testcase*.
>>
>> ## How I think it could work?
>> I think we could change how we approach the core applications, how we
>> test them and where we test them. For example:
>>
>> * A list of generic core applications should be made (or the old list
>> used, see above), so that core applications are not limited to a certain
>> desktop environment (although we only test Gnome). By *generic* I mean that
>> we should not explicitly say, if the terminal application is
>> *gnome-terminal* or anything else. We only say it is a *terminal*
>> application and each spin will pick up what suits best for them.
>> * Core applications should be promoted to be a part of all Fedora spins.
>> It should not happen that a spin is missing a core application after a
>> clean installation.
>> * The presence check (that the apps are installed) could be easily done
>> by OpenQA. Possibly, it could be done even for more DE than just Gnome,
>> hence we could enhance the user experience for spin users.
>> * Functionality of the applications should be redefined - what we expect
>> for them to be doing - and this functionality should be required. I
>> suppose, that we would only block on Workstation functionality, though.
>> However, these guidelines could help the spin teams to decide which apps to
>> use as core apps.
>> * *Core applications* should not just have a basic functionality, as
>> defined in *Gnome Menus testcase* (
>> https://fedoraproject.org/wiki/QA:Testcase_desktop_menus), they should
>> be fully functioning.
>>
>> Before I focus on details, I would like to know your opinions on this
>> matter.
>>
>> Thank you.
>>
>> To reply, visit the link below or just reply to this email
>> https://pagure.io/fedora-qa/issue/569
>>
>>
>> --
>>
>> Lukáš Růžička
>>
>> FEDORA QE, RHCE
>>
>> Red Hat
>>
>> 
>>
>> Purkyňova 115
>>
>> 612 45 Brno - Královo Pole
>>
>> lruzi...@redhat.com
>> TRIED AND PERSONALLY TESTED, ERGO 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
>>
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO 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

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Julen Landa Alustiza]

Related to this and server, and remembering that we had a non working cron
issue proposed as blocker but we didn't have a clear criteria that was
violated to accept the blocker bug, but the majority of the meeting
attendees was in favour of blocking because cron was not working on server
edition and that was a big issue... could we discuss about having blocking
core applications on server flavour? just some basic services, sshd, cron,
systemd...

El mié., 7 nov. 2018 11:35, Lukas Ruzicka  escribió:

> Hello Fedora QA and friends,
>
> I would like to propose a change of what we define as core applications
> because I feel that how it is done today is not sufficient. Let me explain.
>
> ## How it works today?
>
> The *core applications* are defined in this testcase (
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications).
> In our matrices, the core applications are only tested for Gnome
> Workstation. The appropriate test case (
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications)
> requires that all core applications are installed on the system and that
> they start. The functionality is apparently tested by the *Desktop Menus
> Testcase*.
>
> ## How I think it could work?
> I think we could change how we approach the core applications, how we test
> them and where we test them. For example:
>
> * A list of generic core applications should be made (or the old list
> used, see above), so that core applications are not limited to a certain
> desktop environment (although we only test Gnome). By *generic* I mean that
> we should not explicitly say, if the terminal application is
> *gnome-terminal* or anything else. We only say it is a *terminal*
> application and each spin will pick up what suits best for them.
> * Core applications should be promoted to be a part of all Fedora spins.
> It should not happen that a spin is missing a core application after a
> clean installation.
> * The presence check (that the apps are installed) could be easily done by
> OpenQA. Possibly, it could be done even for more DE than just Gnome, hence
> we could enhance the user experience for spin users.
> * Functionality of the applications should be redefined - what we expect
> for them to be doing - and this functionality should be required. I
> suppose, that we would only block on Workstation functionality, though.
> However, these guidelines could help the spin teams to decide which apps to
> use as core apps.
> * *Core applications* should not just have a basic functionality, as
> defined in *Gnome Menus testcase* (
> https://fedoraproject.org/wiki/QA:Testcase_desktop_menus), they should be
> fully functioning.
>
> Before I focus on details, I would like to know your opinions on this
> matter.
>
> Thank you.
>
> To reply, visit the link below or just reply to this email
> https://pagure.io/fedora-qa/issue/569
>
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> 
>
> Purkyňova 115
>
> 612 45 Brno - Královo Pole
>
> lruzi...@redhat.com
> TRIED AND PERSONALLY TESTED, ERGO 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
>
___
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

Fwd: [fedora-qa] Issue #569: Proposal to redefine core applications.

[Lukas Ruzicka]

 Hello Fedora QA and friends,

I would like to propose a change of what we define as core applications
because I feel that how it is done today is not sufficient. Let me explain.

## How it works today?

The *core applications* are defined in this testcase (
https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications).
In our matrices, the core applications are only tested for Gnome
Workstation. The appropriate test case (
https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications)
requires that all core applications are installed on the system and that
they start. The functionality is apparently tested by the *Desktop Menus
Testcase*.

## How I think it could work?
I think we could change how we approach the core applications, how we test
them and where we test them. For example:

* A list of generic core applications should be made (or the old list used,
see above), so that core applications are not limited to a certain desktop
environment (although we only test Gnome). By *generic* I mean that we
should not explicitly say, if the terminal application is *gnome-terminal*
or anything else. We only say it is a *terminal* application and each spin
will pick up what suits best for them.
* Core applications should be promoted to be a part of all Fedora spins. It
should not happen that a spin is missing a core application after a clean
installation.
* The presence check (that the apps are installed) could be easily done by
OpenQA. Possibly, it could be done even for more DE than just Gnome, hence
we could enhance the user experience for spin users.
* Functionality of the applications should be redefined - what we expect
for them to be doing - and this functionality should be required. I
suppose, that we would only block on Workstation functionality, though.
However, these guidelines could help the spin teams to decide which apps to
use as core apps.
* *Core applications* should not just have a basic functionality, as
defined in *Gnome Menus testcase* (
https://fedoraproject.org/wiki/QA:Testcase_desktop_menus), they should be
fully functioning.

Before I focus on details, I would like to know your opinions on this
matter.

Thank you.

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-qa/issue/569


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO 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