It would be nice to have working sound on virtual machines as well. If you could add
instructions or note(s) whether this would be possible at this stage it would be
appreciated.
If it should work, it could be tested as well.
(There are some challenges even with current sound systems, so it is not criteria, more
like a suggestion for a test case).
Jan Kuparinen
________________________________
From: Kamil Paral <kparal(a)redhat.com>
Sent: Wednesday, January 27, 2021 7:52 PM
To: For testing and quality assurance of Fedora releases
<test(a)lists.fedoraproject.org>
Subject: Re: Proposal to modify: Working Sound Beta Release Criterion
On Mon, Jan 25, 2021 at 1:59 PM Kamil Paral
<kparal@redhat.com<mailto:kparal@redhat.com>> wrote:
On Thu, Jan 21, 2021 at 2:20 PM Lukas Ruzicka
<lruzicka@redhat.com<mailto:lruzicka@redhat.com>> wrote:
Hello friends of Fedora,
I have been thinking about a proposal to modify the %subj.
It's good to link to the existing version, so that people can compare:
https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria#Working_sound
I have tried several version and I did not like any, so finally I am proposing this
text:
Working sound
The installed system must be able to play back and record audio.
This probably needs something like "(if relevant hardware is present)" appended
to it (or in a footnote). And we should keep the existing "System-specific bugs"
footnote from the current criterion.
I believe the proposed change is good for two main reasons:
1. I don't see a reason to limit the criterion to just gstreamer-based applications,
as it currently is.
2. Audio recording has grown in importance immensely in the last year due to
teleconferencing and we should cover it in criteria.
So I'm fine with the proposal.
There's a question whether this should stay in Beta or be moved to Final, since it
covers more use cases in the new version. Personally I think it's OK to keep this in
Beta, because, quoting from the footnote, "It is meant to cover bugs which completely
prevent sound playback from working in any hardware configuration". Less clear-cut
cases can be decided as Final during blocker review, and we also still have the Default
application functionality [1] for Final, which furthermore covers some important apps by
itself.
One additional thought, I would also be OK with keeping "sound output must work"
criterion for Beta, and "sound recording must work" criterion for Final. That
also seems reasonable.
Is there no-one else who has any opinion on all this? Where is everybody? ðŸ”