Peter Boy <pboy(a)uni-bremen.de> writes:
> Am 25.02.2022 um 23:19 schrieb Adam Williamson
> On Fri, 2022-02-25 at 22:35 +0100, Dan Čermák wrote:
>> Hi Peter,
>> Peter Boy <pboy(a)uni-bremen.de> writes:
>>> Excuse my ignorance, but I'm just wondering what sense the regular
rawhide "compose check reports" make. Who processes this information?
>> I am pretty certain that Adam and probably other members of Fedora's QA
>> team review these reports and decide whether the compose is good to go
>> or not.
I hope my wording did not have the wrong connotation. I didn't want to doubt the
usefulness, but to clarify if Server WG is expected to watch and to take care, or if
it's a pure information, and others like QA Team take care of it primarily (and
contact Server WG if necessary or helpful).
Not at all! The openQA tests are rather specific and hard to analyze &
triage for anyone who isn't really familiar with the system
themselves. Requiring others to take care of test failures in openQA
would be a pointless waste of everyone's time. Afaik the process is
roughly like this: If tests fail, then the QA team takes a look at
them. If it turns out to be an actual bug and not just a fluke, then the
QA files a bug against the corresponding component with a reproducer, so
that the maintainer can take a look.
Adam, please correct me if I'm wrong!
> It's meant to give anyone who's interested a quick
overview of the
> day's status, and anyone can review the results. The failed tests are
> linked directly. If you find the volume a bit much, the topic is easy
> to filter to a separate folder - this is what I do in fact (I filter
> these reports and the "compose report" mails generated by releng to a
> dedicated Reports folder).
> When I have time I send a manual reply explaining the failures, but 36
> and Rawhide have both been pretty chaotic lately so I haven't had time.
> Very broadly, most tests are actually passing now, a few are affected
> by known bugs. Most of interest to Server is that the aarch64 disk
> images are affected by
> not run on first boot as it should).
thanks for the information. As you may have noticed I’ve initiated a discussion how to
contribute to improve Server release quality and to avoid some unpleasant experiences that
we had with the last releases. Those type of issues may not be detectable with automated
tests. Unfortunately, I lack an overview of the processes. I have never had any reason to
get familiar with them until now (unexpectedly having become somehow engaged in server
I am not Adam, but I'll ask anyway: what issues did you encounter?
openQA is pretty versatile and can test *a lot* of scenarios.