Hello, I am afraid that I would rather see the code been cleaned up than to be sliced in small thunk to keep non functional code that might be used somewhere else.
The source management model that we use in Tizen, allows us to progress Tizen 3 without affecting Tizen 2 legacy and we shall take profit of that feature. In short we need to keep the common part runing on Common code and let the profile define patches if they have very specific use case, what I hope will be the exception. So the requirement to keep the Old code untouched shall not apply. If Mobile has specific requirements they should take profit of the Gerrit review to voice their opinion, in order to enable the Common code to serve common needs. Regards -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre Le 05/12/2014 09:01, Zheng, Wu a écrit : > Hi Bluetooth-Frwk guys, > > Some modification of Bluetooth-Frwk (in Tizen branch) are needed to fix the > TIzen Common issues. > The related bugs need to be fixed to match some time points. > > Therefore, the following patches have been submitted. > https://review.tizen.org/gerrit/#/c/30969/ > https://review.tizen.org/gerrit/#/c/30970/ > https://review.tizen.org/gerrit/#/c/30968/ > https://review.tizen.org/gerrit/#/c/30971/ > > Not make sure that the related patches will impact on the other platform. > > If it is, " __TIZEN_MOBILE__ " is needed to be added to keep old source code > match the related platform. > > If not, it will be accepted to match TIzen Common and fix the related bugs. > > Some suggestions? > > Best Regards > Zheng Wu > >> -----Original Message----- >> From: Dev [mailto:[email protected]] On Behalf Of >> [email protected] >> Sent: Monday, December 1, 2014 8:43 PM >> To: [email protected] >> Subject: [Dev] bluetooth-frwk changes >> >> Hi all, >> >> I'm working on fixing bluetooth related bugs for the M14.4 IVI release. >> >> To do so, I found few limitations/constraints in bluetooth-frwk, I'd like to >> change: >> >> - bt-service daemon automatically enables bluetooth. >> --> I would like to keep bluetooth state as it is and align accordingly >> vconf bt >> status key. >> >> - in each bluetooth CAPI call, bt adapter state is checked. Currently CAPI >> directly >> checks the status over Bluez property. >> --> I would like to make this check in bt-service. By this way, bt-service >> can be >> launched by dbus activation (when checking bt state at bt init phase for >> instance). >> >> The main goal here is to clean up tizen bluetooth crosswalk extension >> intialization in fixing IVI bluetooth bugs. >> In addition it will unify initialization phase in case of NTB or >> bluetooth-frwk >> component. >> >> Does someone see a problem with this approach ? >> >> Thanks and regards, >> Corentin >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
