Consider me 0. I was not able to follow the discussion and I'm leaving for vacation. If I'm the last missing vete, I'm happy to reconsider.

(I'm supportive of this coinage in general, I'm just not following all the discussion.)

+1

+1

I'm pretty sure we need to move the contingency deadline earlier. If we start to revert this change right before beta freeze, beta freeze would be delayed. Please move the contingency deadline one week earlier.

"slaved" — we now have an initiative to replace "enslaved" and similar words. In this particular case, I think "slaved" is actually rather unclear to users. At least I have no idea what it means in this context. So maybe "inheriting configuration" or "connected under ..." whatever else makes sense in this context.

" install the pipewire-pulseaudio library" — this contains the daemon, right? So you probably want to say "package" not "library". Please specify the command to do this. Just doing dnf install pipewire-pulseaudio fails with conflicts, and dnf install pipewire-pulseaudio --allowerasing wants to remove gdm, in current rawhide.

In "How to Test" — it'd be nice to have command to directly check daemon status. Is pactl the the best we have?

+1 with "early" revert if it proves to be not ready.

And I would also like the installation instructions to be more detailed than "install it", and have them actually work, so people can actually test it ...

I agree with @zbyszek here, the contingency deadline needs to be earlier. There are a lot of parts here and beta would be too late.

This statement concerns me: "pipewire-pulseaudio does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later."

While that is fine, I feel a feature like this needs more careful introduction in to Fedora. In the past Fedora has offered changes like this on an opt-in basis for at least one or more releases in order to ensure things work well and are stable for a larger portion of users. Since this is impacting the audio stack, I have a concern for a stable release of Fedora potentially having an unusable audio stack for video conferencing software. Since we're in a pandemic now and more of us are reliant on that, I would like to know that I can upgrade my Fedora systems and still trust the audio stack. That is why I would like to see this as offered as an option for users to try but still have the ability to fall back on what we currently have.

From a technical standpoint, PipeWire looks really appealing. I want to migrate to it and test things out. But I do want to be cautious regarding critical end user software.

-1 as written. Would like to see:
Earlier contingency deadline
Details on what end users would see regarding this change (device changes, reordering, mixer looks different, etc)
* Plan for either an opt-in offering -or- instructions that help me restore the previous audio stack should I find PipeWire prevents critical applications from working -or- [something else?]

I largely agree with David here. I'm -1 as currently written.

I'd like an earlier contingency deadline (at least one week prior to Beta Freeze) and I'd like the Beta deliverable to include clear documentation on how to revert to the PulseAudio stack in the event of issues.

I disagree with the opt-in offering approach, since this is the sort of feature that will never be truly ready until it's been tested with a wide variety of hardware. It has to happen sometime, might as well happen soon.

Change was approved during today's FESCO meeting

AGREED: approve the change (but with the contingency dealine moved to one week before beta) (+5, 0, 0)

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IEZWN2D3FZNZJIS432I3TKDWVGEZD7SW/

AGREED: approve the change (but with the contingency dealine moved to one week before beta) (+5, 0, 0)

That deadline is now. @wtaymans can you confirm that the change is on track for F34 and we don't need to invoke the contingency deadline? (That is my understanding, but an explicit confirmation would be good).

I see that the change page still doesn't have instructions how to opt-out. We really need that.

I see that the change page still doesn't have instructions how to opt-out. We really need that.

This is done and now added to the Change page.

That deadline is now. @wtaymans can you confirm that the change is on track for F34 and we
don't need to invoke the contingency deadline? (That is my understanding, but an explicit
confirmation would be good).

The change is on track for f34. I feel confident that we don't need to roll back.

I'll continue here since it seems to be better than to start yet another discussion thread.

The page says:

The pulseaudio package will be uninstalled and pipewire-pulseaudio will be installed.

But that doesn't happen on upgrades (I just upgraded to F34). I had to do sudo dnf install pipewire-pulseaudio --allowerasing. (Though things were working fine before that (with both pulseaudio and pipewire simultaneously enabled), and after that (with just pipewire active). So this is not about something broken, but about driving this change to the end.)

I think existing systems should be updated to the new default on upgrades, if possible. We always have this discussion when changing a default. But I think in this case my preference falls strongly on the side of updating: audio has interactions with many different components and it'll be easier to debug things if we know that all users have the same system by default.

Is there a plan to force the upgrade somehow?

Is there a plan to force the upgrade somehow?

There is, I just haven't figured out what the correct mechanism for this is yet. I only started trying to figure that out after we passed the revert checkpoint, since there's no point in trying before then.

Good to hear that.

There is, I just haven't figured out what the correct mechanism for this is yet. I only started trying to figure that out after we passed the revert checkpoint, since there's no point in trying before then.

time for?

Obsoletes: pulseaudio

Well, I need to be careful so that if someone explicitly switches back, it doesn't do it over and over.

Obsoletes: pulseaudio

We want people to be able to switch back to pulseaudio. I think Obsoletes would cause a problem.

What about adding Recommends:pipewire-pulseaudio in pipewire?

Obsoletes: pulseaudio

We want people to be able to switch back to pulseaudio. I think Obsoletes would cause a problem.

What about adding Recommends:pipewire-pulseaudio in pipewire?

That will get blocked on upgrade, we need a deliberate forced transition from pulseaudio to pipewire-pulseaudio.

Would something like this work?

%package pipewire-pulseaudio
Obsoletes: pulseaudio < first version in F34, but no later versions

That should force the change on upgrade (because pipewire on f33 is older) but not later (because the Obsoleted pipewire version is not in F34). The downside would be that you'd have to keep that updated if pipewire on f33 is updated.

Adding Obsoletes for the pulseaudio modules that get removed with --allowerasing to the Obsoleted packages too should get rid of the --allowerasing argument too?

I think you mean PulseAudio, but yes, I get the idea...

Yeah I fixed it with an edit in the original comment :)

Even easier should be using Epoch: 1 in pulseaudio in F34+ and only obsolete pulseaudio packages with Epoch: 0, but I'm not sure how that would look like in RPM .spec syntax ...

Obsoletes: pulseaudio < 1: does not look right.

That'd have to be Obsoletes: pulseaudio < 1:0.

But I don't think we want to play with epochs here.

+1 for Obsoletes: pulseaudio < "first version in F34".

That's what I've gone with: https://src.fedoraproject.org/rpms/pipewire/c/a94724fe232c165c13f8510148c4f85a4fa76351

@ngompa could you also add Obsoletes for all the other pipewire modules that need to be removed on upgrade? On Workstation, that's at least pulseaudio-module-bluetooth and pulseaudio-module-x11, otherwise the upgrade will not work without --allowerasing (and I'm not sure if the dnf system-upgrade plugin, or the gnome-software system upgrade plugin, for that matter, support supplying that argument at all).

Yeah, I can do that.

How does this look? https://src.fedoraproject.org/rpms/pipewire/c/093eaf8f12cbcd2b8a2bb12e442490bce0df0039

What about pulseaudio-module-{gconf,gsettings,lirc,zeroconf}?
Not sure about pulseaudio-qpaeq but if it's installed, it will block upgrade too.

Hmm, I guess it makes sense to obsolete everything except the utilities.

Added everything except libraries and utilities: https://src.fedoraproject.org/rpms/pipewire/c/7bb7a583023cfc961090a943b0b69223df89bfaa