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, <jprvita at gmail.com> wrote: > > From: Jo?o Paulo Rechi Vita <jprvita at openbossa.org> > > > > 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
