On Wed, Nov 25, 2020 at 7:49 AM Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
On ke, 25 marras 2020, Wim Taymans wrote:
>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
>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
>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
>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?
真実はいつも一つ！/ Always, there's only one truth!