On Wed, Nov 25, 2020 at 7:49 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On ke, 25 marras 2020, Wim Taymans wrote:
Hi all,
First of all, thanks for the comments, keep them coming. We have seen these concerns many times before with big infrastructure changes like pulseaudio or wayland or systemd. I think they are necessary to keep our feet on the ground and not get carried away by our pipe dreams (pun intended).
As the author of PipeWire and creator of this Change proposal, I will try to address some of the concerns I see here in the comments:
It needs more testing...
This change request is about enabling PipeWire audio by default *for testing* in a testing environment. I'm proposing this because I think it is ready for *testing*. I hear some claims that it is too early to test; as the main developer, I disagree. It's not too early to test. People have been running PipeWire as the main audio backend for some time now, and so can you.
The goal when enabling this by default is to have a nicely integrated solution that people can try, test and revert. This will give us more testers and feedback and bring us closer to the final goal.
but I can't even enable it to test! packages don't install and have conflicts!
We're working on getting the dependencies right on other packages so that we can actually swap implementation.
Should we have waited until this works better? perhaps.
We ask for some patience until this is fixed, I expect this to be testable next week. Stay tuned for an update.
This is going to be so buggy, why do this to us
The feedback from early testers give me confidence that it will not be all doom. There will be bugs, they will get fixed and you'll have to retest. It is how to move forward.
By the end of the testing and the beta freeze we end up with a nice list of bugs and must-have features that people found (or not) and we roll back (or not).
why bother, this will fail and we'll have to roll back anyway
I have no problem whatsoever with rolling back after an honest round of testing. This proposal will be resubmitted for the next release and we try again. But, this would be all pointless without taking the risk to actually test the new things first.
it's still in active development
A project like this takes time to develop and will hopefully be in active development for many more years. There are so many ideas remaining...
Development of the video parts started in early 2017, more than 3 years ago and ended up in fedora 27 as a dependency for screencasting.
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
How can we make sure audio replacement doesn't end up in the same state?
That is a bug with GNOME. I have been using Plasma Wayland screencasting perfectly with Plasma 5.20 on Fedora 33 with all three this week. Could you please file a bug report against gnome-shell about the issue?