>> It's not a good way to patch gecko code I agree with Shawn. And for my experience, I had tried to propose the "patch" mechanism and reviewer strongly rejected it. The reason is that "all patch should be reviewed well then commit into repository" Then I kept this principle when I reviewed other devices manifest.
If this is a case we allowed then I can't say no for following requests from partner. Do we allow it? ----- 原始郵件 ----- 寄件者: "Shawn Huang" <[email protected]> 收件者: [email protected] 寄件備份: 2014 3 月 8 星期六 上午 12:37:43 主旨: Re: [b2g] Master hamachi build failure On Saturday, March 1, 2014 12:19:06 AM UTC+8, Shawn Huang wrote: > On Friday, February 28, 2014 11:09:48 PM UTC+8, Sotaro Ikeda wrote: > > I don't know why. Since hamachi is ICS based and still uses bluez as the > bluetooth stack. This patch is not necessary for hamachi, now only JB/KK uses > bluedroid as the bt stack. I think you can delete the patch locally. It looks > like caf has their own modification for bluetooth HAL header files, and since > we followed AOSP bluetooth HAL (at least I think we shall follow aosp HAL), > caf tries to patch our gecko code to match their HAL headers. Auto patch > failed because recently change file path in bug 972732. > It's not a good way to patch gecko code, especially HAL headers changed and patches are under device/qcom/b2g_common/patch/all/gecko. How do we handle this kind of HAL changes? Can anyone please enlighten me? How do we choose to support AOSP HAL or CAF HAL? _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
