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