On Wed, Nov 25, 2020 at 7:49 AM Alexander Bokovoy <abokovoy@xxxxxxxxxx> 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? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
