On Wed, Jan 27, 2021 at 7:35 PM Adam Williamson <adamwill@fedoraproject.org> wrote:
The reason the current criterion specifies "with gstreamer-based
applications" is to avoid being too broad and vague. It really *means*
"sound must basically work", but we're referring to gstreamer on the
basis that:

1. It's the framework our primary desktops and apps use
2. It is actively maintained and can reasonably be expected to keep
working *as a framework*

...so it excludes problems like "this app's audio code just doesn't
work" or "this app uses some obscure framework that isn't maintained
properly and isn't working" from being potentially considered blockers
while making sure that if *some* random app can play audio but all
gstreamer apps are broken, we should consider *that* a blocker.

I went through several iterations, each time proposing the new criteria completely differently, then realizing something, deleting everything and getting back to the drawing board. I ended up with basically agreeing to keep the Beta criterion untouched :-D It would be too much of a wall of text to explain all my thoughts, but the key takeaways are:
* At Beta, we can't tie this criterion to a specific app (the default video/audio player) or all relevant apps installed by default, because we don't even require them to start. All which must start and function on a *basic* level is a terminal, a web browser (with very limited functionality) and a graphical package manager, that's it. So instead defining this as a class of applications relying on the most common multimedia framework (regardless of whether they are preinstalled or not, because those preinstalled are not required to work) makes sense. Not only that it requires hardware to work, but it also requires at least one app (and the framework) of this class to work, which is fine.
* The default web browser (Firefox) is not among the specified class of applications (it doesn't seem to use gstreamer, according to rpm deps). But that's probably fine, because at Beta we don't really require most apps to work anyway (not even a file browser, haha:)), so requiring working sound in the browser would probably be a stretch anyway (at Beta, it doesn't even have to display video properly atm).
* At Final, everything changes due to the Default application functionality criterion. That takes care of a working sound output for all preinstalled apps on Workstation, and at least the web browser on other desktops.

So, it seems that a working sound output is actually covered well-enough in our criteria (unless we want to be more strict in Beta, but that should be coupled with further changes, if it should make sense).

The recording criterion could then be added into Final:
Final: "The installed system must be able to record audio using the default web browser (if applicable) and gstreamer-based applications."

I chose to call out the web browser, because while most people would probably agree that a working sound output is the expected Default application functionality nowadays, it might not be that clear-cut with a sound input. I believe we really want this due to current teleconferencing needs. Additionally, I used the same approach as with the sound output criterion - refer to gstreamer. Mostly because sound recording apps are not generally pre-installed, so it doesn't make sense to depend on those. This approach also works well with text-based environments (like Server), because the web-browser part doesn't apply there and so you can go and install some of the apps from the covered set and test it.

We should again understand this as "some (not all) gstreamer-based apps must work, showing that the gstreamer framework works and hardware works", so a similar footnote as in the existing Beta criterion ("System-specific bugs") might be needed here as well.

Thoughts?