Comment 384 for bug 371897

> The fact of the matter is it's not simple or it would have been done years ago.

...which, in fact, it was.

Listen, Ben Klein, that's enough. I was a respected Wine developer years ago. *I* once tweaked all these audio drivers to have decent performance, where they didn't before. *I* once wrote code to make wineoss and winealsa dsound-capable, where they once weren't so hot. Even now, I would be able to whip up a pulse driver in a jiffy, except it has already been done, and I have better things to do. So, hear me: there are *no* unresolved technical reasons for not being a winepulse driver in Wine. It's all politics.

Now, I understand the political arguments. I understand the code maintenance concerns, the design issues, the feeling that the current audio subsystem has become an abomination. I understand that and I even agree. It's perfectly understandable to me that they don't want to make the monster grow further by adding yet another driver to the legacy design, and would rather rewrite the subsystem first, in order to get a more streamlined and maintainable design for the future. I don't have a problem with that. I understand why they'd be happier to stick with pulse's alsa emulation, if it would just work. Why they'd rather force someone to bang that alsa emulation into working if necessary, rather than prolong the pain of maintaining the current subsystem.

Alexandre Julliard has, indeed, employed such measures in the past - i.e., sometimes he'd rather force people to rewrite parts of Wine before allowing them to add features on top of those parts, if he thinks those parts are flawed in some way. In such cases, the technical merits of the new feature isn't the reason for his rejection - it's just his way of getting people to do more work for Wine. Before a Wine contributor can scratch his/her own itch, Alexandre might make sure he/she scratches someone else's related itch first - or at least doesn't cover that other itch up so much that it'll never be scratched.

I won't push for the inclusion of winepulse in its current incarnation. However, I *do* have a general problem with people who aren't telling the truth. The reasons for not including winepulse are *not* technical, they are code policy decisions (and probably fairly good decisions, at least from certain perspectives, but nevertheless undeniably political). So, stop spreading lies, stop acting like you know what's going on, and stop berating users that are seeing right through you. What these users want is perfectly reasonable, and even if there may be good political reasons not to give them that quite yet, they don't deserve being flamed by someone parroting obsolete arguments that were only half-true even when they were new. I think they have a right to actually know what's going on.

There's no technical reason for winepulse's non-inclusion. It's all about a line in the sand. A piece of less forward-thinking engineering within Wine itself, that Wine developers don't want to see grow more arms. I'll even take some of the blame for propagating that design myself, back when I could have done something about it and perhaps should, but didn't, and instead probably just made it worse. A little piece of this mess is *my* fault. And now people have to suffer for that. That's the way of politics, good or bad. At least, it's certainly not about any technicalities of the winepulse driver itself.