On ma, 29 elo 2022, Adam Williamson wrote:
On Tue, 2022-08-30 at 00:32 -0400, DJ Delorie wrote:
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 ;-)
No, not really, sorry if I didn't explain clearly enough :D It's more
just a 'what's the best way to work what I want to do around the
existing definitions' question. What I want to do is have updates of
FreeIPA-related packages gated. The awkwardness is that right now the
definition of what gets gated is "critical path packages", and those
clearly don't meet the current definition of "critical path".
Not all of them meet the current definition of 'critical path' but many
do. In fact, almost all crypto-implementing packages should be on that
list, if not already.
Ideally, use of gating tests should be defined in the component itself.
Do we have a mechanism to trigger OpenQA runs from the gating.yaml in
the specific component? If we do, then we really should move it there.
Another part of the problem is that most of these runs should probably
be consulting, not gating in the sense that failing them should give you
a clue that things might be wrong but there needs to be a human overview
of the failures. It is what we have right now with OpenQA-reported
failures for Bodhi updates in most cases, the test results aren't really
preventing the submissions from the going forward unless a maintainer
defined the update configuration to be so.
Ideally, we should have reverse dependency updates to trigger FreeIPA
tests and give their results a visibility but don't block on failures.
This would give an opportunnity to notice a failurer earlier but don't
discourage maintainers from participating in a joint development.
Perhaps, The Fedora Packager Dashboard could be extended to pick up
results of tests relevant to your packages and display them together?
This way FreeIPA maintainers can see an overview of all tests related to
FreeIPA in one place and see if any help is needed to resolve failures.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
