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=02%7C01%7C%7C4ded8d05283a43fecfe808d646629497%7C84df9e7fe9f640afb435%7C1%7C0%7C636773786545211553=EaLDQ8YR%2BmpZltaiATcjENIFAui%2BmJKzPuswxvoysBU%3D=0
 List Guidelines: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines=02%7C01%7C%7C4ded8d05283a43fecfe808d646629497%7C84df9e7fe9f640afb435%7C1%7C0%7C636773786545211553=Axj9nV0oxK7bi%2BCc9t0rLza65UX3MURAqgniY%2BW8Hlw%3D=0
 List Archives: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Ftest%40lists.fedoraproject.org=02%7C01%7C%7C4ded8d05283a43fecfe808d646629497%7C84df9e7fe9f640afb435%7C1%7C0%7C636773786545211553=Rtmjj9Nq7OfKWdSrpuvlNhLX5%2BZhNBMULrq1I3TPmYs%3D=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.

[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, 

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 

Fedora Rawhide-20181109.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 37/142 (x86_64), 9/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20181105.n.1):

ID: 306907  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/306907
ID: 306908  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/306908
ID: 306934  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/306934
ID: 306936  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/306936
ID: 306937  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/306937
ID: 306938  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/306938
ID: 306951  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/306951
ID: 306954  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/306954
ID: 306985  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/306985
ID: 306996  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/306996
ID: 306998  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/306998
ID: 307015  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/307015
ID: 307016  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/307016
ID: 307038  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/307038

Old failures (same test failed in Rawhide-20181105.n.1):

ID: 306909  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/306909
ID: 306910  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/306910
ID: 306914  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/306914
ID: 306935  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/306935
ID: 306940  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/306940
ID: 306941  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/306941
ID: 306952  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/306952
ID: 306953  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/306953
ID: 306955  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/306955
ID: 306956  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/306956
ID: 306957  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/306957
ID: 306958  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/306958
ID: 306959  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/306959
ID: 306961  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/306961
ID: 306968  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/306968
ID: 306971  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/306971
ID: 306972  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/306972
ID: 306989  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/306989
ID: 306997  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/306997
ID: 307006  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/307006
ID: 307007  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/307007
ID: 307009  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/307009
ID: 307010  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/307010
ID: 307011  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/307011
ID: 307012  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/307012
ID: 307013  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/307013
ID: 307019  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/307019
ID: 307034  Test: 

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.

[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

[Test-Announce] Fedora 30 Rawhide 20181109.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 30 Rawhide 20181109.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20181105.n.1: anaconda-30.8-1.fc30.src, 20181109.n.0: 
anaconda-30.10-1.fc30.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/30

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181109.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181109.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181109.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181109.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181109.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181109.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181109.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-announce@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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-announce@lists.fedoraproject.org