-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We had an extensive conversation last April on fixing updates and a
lot of bugs were filed and work was done. In light of v3, I'd like to
re-open the discussion on this and see where we are.
Last year the conversation seemed to be centered around:
On Tuesday, March 24, 2015 at 3:00:16 PM UTC-4, Dave Huseby wrote:
> What I'm getting at, is maybe there is a third option with vendors
> where we negotiate a "sunset clause" situation. The partners provide
> us with a signed app that "unlocks" their phones before they ship.
> They lock their phone
Dave Huseby 於 2015年03月25日 02:59 寫道:
Has anybody reached out to our partners and taken a survey of the ways
they modify our code for their devices? If there are patterns (e.g.
they all disable feature X) then maybe we should consider abstracting
away that part and make it super easy for them to pr
Hi Dave
> I re-read the old thread and bugs and had a few questions/thoughts.
>
> Has anybody reached out to our partners and taken a survey of the ways
> they modify our code for their devices? If there are patterns (e.g.
> they all disable feature X) then maybe we should consider abstracting
> a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I made update build for ZTE Open C FR/EU from mozfr
> * Making it easier to change the update channels (Developer menu
> now has this).
Yes this will be a good idea (we already think to made an app for
that, so if it's include on B2G it's bette
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/25/2015 02:23 AM, Thomas Zimmermann wrote:
> To solve this problem, we need to move all drivers out of Gecko and
> provide (semi-)stable interfaces that we can support over a longer
> period of time.
I completely agree with this.
> The two cr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I wonder if we created daemons that wrapped all of the vendor binaries
if we could get a situation where vendor FOTA's only included their
binaries and customized versions of our daemons and did NOT include
gecko? If we could get there, then the ven
On 03/25/2015 12:04 PM, Dave Huseby wrote:
> Frankly I'm surprised this abstraction doesn't already exist. I think
> the RIL interface should be moved out to its own daemon so that we can
> encapsulate all of the code for the different RIL APIs/versions in
> there and present a stable interface to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/25/2015 12:28 PM, Fabrice Desré wrote:
> On 03/25/2015 12:04 PM, Dave Huseby wrote:
>
>> Frankly I'm surprised this abstraction doesn't already exist. I
>> think the RIL interface should be moved out to its own daemon so
>> that we can encap
On 03/25/2015 01:39 PM, Dave Huseby wrote:
> Yes, I think I wasn't clear. I said "RIL interface" referring to that
> set of xpcom components.
>
> Do the vendors customize the interfaces and dependencies between gecko
> and their xpcom components? Do they modify our code to call into
> their custo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/25/2015 01:57 PM, Fabrice Desré wrote:
> Yes the ril team works closely with partners. The technical issue
> is that a binary xpcom that has been built against gecko version X
> can't be loaded by gecko version Y because we don't guarantee this
To note: this was one of the reasons why QA didn't have a working build for Leo
for several months. We had to get some checks in place amongst other issues.
It's also why the version check is in place in the first place.
On Mar 25, 2015, at 1:57 PM, Fabrice Desré wrote:
> On 03/25/2015 01:39 P
On 03/25/2015 02:06 PM, Dave Huseby wrote:
> On 03/25/2015 01:57 PM, Fabrice Desré wrote:
>> Yes the ril team works closely with partners. The technical issue
>> is that a binary xpcom that has been built against gecko version X
>> can't be loaded by gecko version Y because we don't guarantee this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/25/2015 02:14 PM, Fabrice Desré wrote:
> I tend to think we need to move away from xpcom here instead.
Sure, let's do it. Design and build a regular plugin API. They ship
a .so plugin we load. That would give us a well defined interface and
Hi
Am 25.03.2015 um 20:28 schrieb Dave Huseby:
> I wonder if we created daemons that wrapped all of the vendor binaries
> if we could get a situation where vendor FOTA's only included their
> binaries and customized versions of our daemons and did NOT include
> gecko? If we could get there, then
15 matches
Mail list logo