On Thu, 2014-04-03 at 21:34 +0200, David Henningsson wrote: > On 04/03/2014 11:07 AM, Tanu Kaskinen wrote: > > Hi all, > > > > There's a big pile of routing patches from me that haven't been merged > > to master. Some of them have been reviewed and are in the "routing" > > branch, and some (most) are pending review. The plan was that Arun would > > review them, but it turned out that he doesn't have time for that after > > all. It appears that nobody has time to review those patches, so to > > avoid blocking the work forever, I plan to start pushing them to master > > without waiting for reviews any longer. If anyone has objections or > > questions about this, let me know. > > > > I don't expect the merging process to happen overnight, because > > currently most of my time goes to the Tizen volume API, and there's > > probably also significant amount of rebasing work to do (the routing > > branch forked from master in September). > > When I stopped reviewing (mainly due to lack of time), the patches added > more complexity than it solved actual problems. I tried to point that > out repeatedly last year and help you back on track, but the latest was > a "I give up" here [1]. If this situation has not changed significantly > since, my opinion is that I don't we should merge anything of the > routing work to master. This is because the cost of the added complexity > weighs heavier than the benefit of added features (or solved problems). > If it has changed significantly, could you give a summary on why I > should re-evaluate this opinion? I don't think there's significant change. So you want to trigger merging only once there are significant benefits for users. Peter and Arun, what's your opinion, is this a fair requirement? What benefit would be significant enough? Which of these (if any) would be sufficient? 1) Automatic port switching when an application wants to play to an inactive node: "paplay --routing=some-inactive-port-node foo.wav" 2) Support for loopback routing without loading module-loopback manually: "pactl set-node-routing some-input-port-node some-output-port-node" 3) Support for automatic combine sink creation: "pactl set-node-routing some-playback-stream-node output-node1,output-node2" 4) A Murphy module that uses nodes for routing 5) Non-Murphy routing module that does something smart (please define "something smart") 6) Something else > But a related question, if it's suddenly okay to push complicated stuff > without review, should I go ahead and push my Ubuntu phone stuff as > well? It's been waiting for review for about half a year now. It appears to be rather self-contained, and doesn't add any public API, so if you prefer pushing it now instead of waiting for review, I'm OK with that. -- Tanu
