On Tue, Jul 16, 2013 at 6:20 AM, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > 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. > The main reason was to make sure that the BlueZ 4 modules are free from BlueZ 5 code and working in the exact same way as before. But also because I found easier to write do it this way, since there is much more code in the BlueZ 5 new modules than the code that was removed from the BlueZ 4 modules. And at this moment I really don't want to spend more time to change that, let's try to focus on having this ready for the next (3.10 IIRC) GNOME release, which the freeze is August 19th (but we should have the code in master before that, to allow time for release and downstream testing). > 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? > It was already agreed before that we would do it this way, and I don't think we should do a D-Bus roundtrip just to detect the BlueZ version. Right now we're compiling both modules by default and generating a default.pa that loads module-bluez4-discovery by default, so IMO it's already good enough to help packagers do the right thing. I'm not exactly sure what's the situation you want to improve not breaking configuration-file compatibility, but one way might make you happy is if we do not rename module-bluetooth-* to module-bluez4-* at this moment, and later when we decide to make BlueZ 5 support the default one we rename module-bluetooth-* to module-bluez4-* and module-bluez5-* to module-bluetooth-*. This will save us from breaking configuration files, but at the price of making the codebase a bit more confusing IMO, which I'm fine with as long as we have a good rationale for that. P.S.: I'm on vacations atm and will be in a road trip for the next 8 days, so I'll be with limited access to email and testing devices. But I'll do my best to read and fix comments to the path series ASAP. -- Jo?o Paulo Rechi Vita http://about.me/jprvita
