On Sat, 2013-07-13 at 09:06 +0200, Mikel Astiz wrote: > Hi João Paulo, > > On Fri, Jul 12, 2013 at 8:06 PM, <[email protected]> wrote: > > From: João Paulo Rechi Vita <[email protected]> > > > > This series reverts the previous support for BlueZ 5, renames the > > "bluetooth" > > portion of the old modules name for "bluez4", creates a new set of modules > > for > > BlueZ 5 supporting A2DP sink and source roles, and provides configuration > > options to independently enable/disable each modules set during build. The > > transport acquire/release operations have been reworked to provide a way to > > implement this operations in transport backends out of the bluez5 modules > > core. > > What's the reason to follow the revert-approach instead of doing a > simple split of the existing code? Is it perhaps because the resulting > code is very different to the original one? > > Splitting would be much easier to review instead of starting from scratch.
Indeed. I would have expected João to first create a copy of the file set, and then remove bluez 4 functionality from one file set and remove bluez 5 functionality from the other file set. Another thing (I should have brought this up earlier, but I only realized this today): not having a generic module-bluetooth-discover breaks old configuration files, which I hate (FWIW, I believe Arun doesn't care about breaking configuration compatibility that much, I don't know David's opinion). João, would it be too much to ask from you to write a stub module-bluetooth-discover, which checks the bluez version at runtime and then loads module-bluez4-discover or module-bluez5-discover depending on the detected version? -- Tanu _______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
