Thank you very much for the provided insight in the both discussions.
Is it reasonable to compare “updates-testing” to “staging” in generic software development?
Is it expected to have any form of quality control (done by dedicated team or developers themselves) before the new build is submitted into “updates-testing” for a stable Fedora release?
The big thing with the Mesa issue is that it was very hard to pinpoint from the perspective of end-user. There was no errors, warnings in any kind of log files etc. Things just stopped without any movement and indication of issues.
However, as Jean-Baptiste LEPESME pointed out in the upstream discussion related to the merge request, issue was obvious when running “vkcube --validate” command. However coming up with this requires very specific domain knowledge.
Is it reasonable have some form of sanity/smoke tests being mandatory before build is submitted into “updates-tesing” (as I already asked @airlied without any response so far).
This, together with the improvements to build description you mentioned, may significantly contribute in a positive way to making correct push/no-push decision by maintainers and or proven packagers.
Is the above something Fedora QA team considered?
Is this an actionable plan to move forward?