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. Development and testing of the redesigned audio core started in june 2018 and ended up in Fedora 32. You could already test the audio on f32 and some people did. The core audio parts and API/ABI has been stable since february 2020. Since then we've been working on the use cases, management of devices and streams and tools. We've had a crew of early testers and incredible feedback. I believe It's ready for more testing. > but the pulseaudio replacement server is only 5 weeks old! It is and it works very nicely indeed, I want you to try it. What's more impressive is that it does not take a lot of complicated code to implement this on top of PipeWire. > It's not ready, it needs to mature more, it's too early This may be true but it's too early to make that decision without giving it a round of testing first, IMHO. There are things that are not implemented yet but I think those are not important enough to block general testing. Some thing might simply not be implemented either (like ESD compatibility) and will cause regressions. I want to know what's important for people, what are must-haves. > there is not enough time to test Perhaps not and then we need to roll back and test more in the next rawhide. It should not stop us from starting to test now, when the developers think it's ready for testing. I don't know how to measure when 'enough testing' has been done. It ultimately depends on how confident people feel after using it for a while. > I've tried it and it doesn't work You have not tried what we propose for rawhide and f34 because there is no easy way to install this yet, please stay tuned. We're going to be fixing the dependencies and upgrading to the latest versions to make this easy. Also please tell us what is wrong and please try again after a fix landed. Much of the instability with browsers and music players got fixed after the pulseaudio replacement server was implemented. > but I don't want to test all this This is ok, I can understand that you don't want to deal with possible audio problems. You will have to install pulseaudio again and opt out. You will have to hope that other people do sufficient testing. It is a bit strange when you are running rawhide, but hey. > but this and that is broken, it's all pointless, why bother, you'll never get this fixed in time Maybe so. Please let us know what's broken. It might be an easy fix and we can retest an updated version. Or not, and then it's a blocker and we roll back. But you have to let us know. So my proposal still is: * Make it easy to swap, hopefully get that working smoothly next week. stay tuned. * Enable by default in rawhide * fix bugs, repeat, retest.. * collect final experiences at beta freeze, re-evaluate rollback or not Is this something we can agree on? Wim _______________________________________________ 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
