date:20220829

Re: Thoughts welcome: interface between automated test gating and the "critical path"

2022-08-29 Thread DJ Delorie


It sounds to me like the problem is "how do we best use the available
automated test resources?" so I'll answer accordingly.  Ignore me if I
misunderstood ;-)

We currently have a small list of packages that are gated behind openQA,
and insufficient openQA resources to expand this list to all packages.

We also have a gating system based on karma, where users provide the QA
manually.  At least, one hopes.  The karma system has some
configurability for how much karma is needed, and for how long, etc.

What about a merger of those systems, where the openQA results count as
a type of user, contributing to the status?  Give each package a "QA
Priority" that ranges from "full gating" to "five second rule", where
the openQA resources and the user work together to prioritize and test
packages according to need:

* full gating requires all openQA tests to pass AND meet karma
  requirements, openQA does these first.

* partial gating is like above, but either one (openQA or karma) can be
  sufficient if enough time passes.

* reject only allows an openQA failure to reject an update, but the lack
  of openQA success need not stop it if it has enough karma. (glibc uses
  this paradigm - a ci/cd failure is an automatic reject, but a ci/cd
  pass adds nothing to the consensus needed)

... and so on down the list. Each user, including openQA, can "vote" a
pass or fail, and the rules say how all those passes and fails result in
the update's overall pass or fail.

This would allow the openQA resources to prioritize updates that it
knows *needs* openQA results, which allocating spare cycles to packages
that could benefit from testing but don't require it.  It also means
that additional openQA resources can be put to use immediately, while
still allowing for growth in critical path size, without being wasted on
unseen results.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads-up / for discussion: dnf not working with 1G of RAM or less

2022-08-29 Thread Dusty Mabe



On 8/22/22 20:44, Adam Williamson wrote:
> Hey folks! I apologize for the wide distribution, but this seemed like
> a bug it'd be appropriate to get a wide range of input on.
> 
> There's a bug that was proposed as an F37 Beta blocker:
> https://bugzilla.redhat.com/show_bug.cgi?id=1907030
> 
> it's quite an old bug, but up until recently, the summary was
> apparently accurate - dnf would run out of memory with 512M of RAM, but
> was OK with 1G. However, as of quite recently, on F36 at least (not
> sure if anyone's explicitly tested F37), dnf operations are commonly
> failing on VMs/containers with 1G of RAM due to running out of RAM and
> getting OOM-killed.
> 
> There's some discussion in the bug about what might be causing this and
> potential ways to resolve it, and please do dig into/contribute to that
> if you can, but the other question here I guess is: how much do we care
> about this? How bad is it that you can't reliably run dnf operations on
> top of a minimal Fedora environment with 1G of RAM?

I think we need to stop thinking about this as just a single computer
problem.

In a containerized world you could have numerous containers running dnf
operations on a machine at any given time. Making the dnf operations take
less memory means we'll hit many fewer issues as single machines are
able to run many dnf operations at a given moment.

> 
> This obviously has some overlap with our stated hardware requirements,
> so here they are for the record:
> 
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/
> 
> that specifies 2GB as the minimum memory for "the default
> installation", by which I think it's referring to a default Workstation
> install, though this should be clarified. But then there's a "Low
> memory installations" boxout, which suggests that "users with less than
> 768MB of system memory may have better results performing a minimal
> install and adding to it afterward", which kinda is recommending that
> people do exactly the thing that doesn't work (do a minimal install
> then use dnf on it), and implying it'll work.
> 
> After some consideration I don't think it makes sense to take this bug
> as an F37 blocker, since it already affects F36, and that's what I'll
> be suggesting at the next blocker review meeting. However, it does seem
> a perfect candidate for prioritized bug status, and I've nominated it
> for that.
> 
> I guess if folks can chime in with thoughts here and/or in the bug
> report, maybe a consensus will emerge on just how big of an issue this
> is (and how likely it is to get fixed). There will presumably be a
> FESCo ticket related to prioritized bug status too.
> 
> Thanks folks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Astro-FITS-CFITSIO] PR #1: Update to 1.16

2022-08-29 Thread Orion Poplawski


orion opened a new pull-request against the project: `perl-Astro-FITS-CFITSIO` 
that you are following:
``
Update to 1.16
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Astro-FITS-CFITSIO/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2120427] perl-Astro-FITS-CFITSIO-1.16 is available

2022-08-29 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2120427

Orion Poplawski  changed:

   What|Removed |Added

 Depends On||2122431





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2122431
[Bug 2122431] Review Request: perl-Alien-CFITSIO - Build and Install the
CFITSIO library
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120427
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Request for testing: Fedora 37 pre-Beta validation tests

2022-08-29 Thread Adam Williamson

Hey folks!

So we're in freeze for Fedora 37 Beta now, and the first go/no-go
meeting should be on September 8.

It would be really great if we can get the validation tests run now so
we can find any remaining blocker bugs in good time to get them fixed.
Right now the blocker list looks short, but there are definitely some
tests that have not been run.

You can use the testcase_stats view to find tests that need running:

https://openqa.fedoraproject.org/testcase_stats/37/

For each validation test set (Base, Desktop etc.) it shows when each
test was last performed. So you can easily look for Basic and Beta
tests that have not yet been run. We need to run all of these.

You can enter results using `relval report-results`, or edit the
summary results page at
https://fedoraproject.org/wiki/Test_Results:Current_Summary . That's a
redirect link which will always point to the validation results page
for the currently-nominated compose, which right now is 20220826.n.0.

Sumantro will be running a validation 'test week' starting on
Wednesday, so you can drop by the Fedora Test Day room on
chat.fedoraproject.org to hang out with other testers and get any help
you need in testing. See
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/message/KVVU6JVOKF4WI4ZS6AFLB7IVBCCNKFCX/
for that announcement.

Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

68 matches

Mail list logo