> What we've been considering for apps is blocking all window.open calls
> except open(url, window_name, "auth"). We'd handle these "auth"
> windows with a special UI (make them modal, etc).
That's interesting, and super cool as it uplevels the window.open into a semantically recognizable "time to authenticate" moment. I'd be happy to help think about that as it relates to Persona and to support this emerging convention.
Do you have the sense that we can get other signin mechanisms to do this? Facebook typically puts the window.open() somewhere inside their library, not under the web site/app's control.
> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
>> I spoke with mccr8 and benm about fixing CC and GC pauses specifically. We nomed a few bugs, which were triaged yesterday.
>> I tend to agree with Taras' assertion about this being a non goal but would reframe the assertion as this is not a measurable goal. We can make general improvements but there is no way to know that we have met this requirement. We can measure success and give people a clear target if we rephrase the requirement as something like:
>> Play a 10 minute video (default max length allowed on YouTube) without noticeable pauses.
>> Play game X for 10 minutes without noticeable pauses or skips (jank).
>> Two notes:
>> 1. We may need to specify hardware as older phones/machines will likely have problems.
>> 2. I don't know what to recommend for game X but I'm sure Martin Best can make some suggestions.
> The key question question is would these block. ie would k9o not
> ship/be done without these. I suspect the answer is we would ship with
> out big things like the js improvements.
JP,
I'm confused. Dmandelin worked through a bunch of JS bugs found the ones he thought most pressing to give the most bang for the buck performance-wise. If you would ship without something like that, what *are* you shipping, quality wise?
There are certainly other metrics than performance, but that seems like a rather unusual statement to me.
> On 4/30/12 5:33 PM, JP Rosevear wrote:
>> I'm surprised that the "table stakes" for this is only contacts and
>> apps. I understand that we have a working sync solution for
>> desktop/fennec for the P2 items, but what about bookmarks, passwords,
>> etc on B2G?
> Let's see if I can channel Dan for a second.
> <pm impersonation>
> Most initial users of B2G will use the phone as their primary computing device and will not have another FF instance to sync with.
The fact that those users don't have a personal computer and a phone is their primary device is exactly the reason why they are visiting cybercafes. Out of the people accessing the Internet in Brazil, over half of them are doing it from these sort of places, or schools and universities [1]. And for the ones who do have a computer at home, it is likely shared with the rest of the family. Correlating this with the user profile that we have been investigating for B2G - young and socially active - it makes sense that these are people in the group that is actively engaged with the Internet where they can, which are mostly environments with shared computers.
> So what counts is a backup service for contacts (which are super annoying if lost) and apps (which the user paid for.) The rest is, *initially*, less important, given the expected user profile.
I would say that the opposite is true: because people have intermittent access to the Internet on the desktop, the ability to sync their experiences across these 2 devices can be very important and the use case of being able to log in with your ID into the browser on a shared computer and when you log off have that information on your mobile devices occurs more often and is more important that when people lose their phone or reset it, etc.
Relating to the app purchase matter, do we have any stats with regards to the propensity of Brazilian users to download paid apps? I think we shouldn't prioritize app sync by that factor, which I assume to be lower, because for free apps it is also important to keep whatever information is stored locally on the device, so I would factor in the overall propensity to install apps, regardless whether they are paid for or not. My expectation is that this number is a lot higher than that of paid apps, but it is just an expectation.
>> On 4/30/12 5:33 PM, JP Rosevear wrote:
>>> I'm surprised that the "table stakes" for this is only contacts and
>>> apps. I understand that we have a working sync solution for
>>> desktop/fennec for the P2 items, but what about bookmarks, passwords,
>>> etc on B2G?
>> Let's see if I can channel Dan for a second.
>> <pm impersonation>
>> Most initial users of B2G will use the phone as their primary computing device and will not have another FF instance to sync with.
> The fact that those users don't have a personal computer and a phone is their primary device is exactly the reason why they are visiting cybercafes. Out of the people accessing the Internet in Brazil, over half of them are doing it from these sort of places, or schools and universities [1].
Where does the "[1]" references to? It sounds like an interesting resource.
>>> What I'm saying is, that there is a reasonable chance Native Fennec will
>>> support tablets in the k9o time frame, so tablets may be "free-ish" in
>>> terms of WebRT. I am curious as to why tablets are P3 though.
>> Got it - but I'd explicitly not put *any* effort at all on maintaining a >> tablet build at all, for k9o. While free sounds tempting, the "-ish" >> piece is concerning :), especially since it means we will need dev, qa, >> ux, reviews, build/rel/ etc. to spend time on this.
>> As for why tablets are P3, here are a few reasons:
> Note - its quite possible we get tablet's for free on the Fennec side.
>> * tablets are not a focus for b2g
>> * there really is not a big market for Android tablets
> Irina Sandu can provide data on this.
It is indeed that if we look only at numbers of install base for tablets that is not a high amount when compared to smartphones or desktops (the amount of tablets that will be in usage in 2015 is forecasted to be about the same as the amount of smartphones in use last year).
What is important to note here is that these numbers do not correlate with market importance and influence equally for these 3 different segments: tablets, smartphones and desktops, which means that if install base is an important criteria for prioritization in one case, say smartphones, it is not necessarily equally important for the other.
For tablets, they have an important influence on the mobile Web because they generate a lot of page views, more than a smartphone. A browsing session on a tablet is a few times longer than on a smartphone and as a matter of fact, it looks like screen size inside the tablet segment is directly proportional with the amount of time spent in a session. [1] They are also important because they are generally more powerful and they can more easily support advanced Web applications, which makes them an important segment when we talk about pushing HTML5 adoption.
So my proposal is that for tablet prioritization we look at what are the most relevant factors for what we want to achieve with Kilimanjaro - they might be different than what I mentioned above - and see where that puts them relative with the other platforms.
> Le 03/05/2012 13:58, Irina Sandu a écrit :
>> On May 1, 2012, at 6:27 PM, Ben Adida wrote:
>>> On 4/30/12 5:33 PM, JP Rosevear wrote:
>>>> I'm surprised that the "table stakes" for this is only contacts and
>>>> apps. I understand that we have a working sync solution for
>>>> desktop/fennec for the P2 items, but what about bookmarks, passwords,
>>>> etc on B2G?
>>> Let's see if I can channel Dan for a second.
>>> <pm impersonation>
>>> Most initial users of B2G will use the phone as their primary computing device and will not have another FF instance to sync with.
>> The fact that those users don't have a personal computer and a phone is their primary device is exactly the reason why they are visiting cybercafes. Out of the people accessing the Internet in Brazil, over half of them are doing it from these sort of places, or schools and universities [1].
> Where does the "[1]" references to? It sounds like an interesting resource.
> On 5/2/12 8:18 AM, Robert Kaiser wrote:
>> Ragavan Srinivasan schrieb:
>>> * there really is not a big market for Android tablets
>> That tablet market surely isn't really large, that's true, but among
>> tablets, Android has ~40% (and growing) market share, so it's not as
>> negligible as you may make it sound. The iPad still has ~60% (trending
>> down), but it's by far not like the tablet market would be all Apple and
>> marginally Android.
> When we prioritize our dev/test time for Android tablets, Amazon's Kindle Fire tablet should be a high priority.
> The Kindle Fire is 54% of Android tablet marketshare. The runner up is Samsung's Galaxy Tab family, which dropped from 23% to just 15%.
Some context to this number is that it is US-only and also that the Barnes & Noble Android-based tablets were considered eReaders for the analysis, so were not included in the calculation. That is not to say that the Kindle Fire has not had an impact on the *US* tablet market, but I would not put that number high on the criteria list for how we prioritize dev time.
> I would say that the opposite is true: because people have
> intermittent access to the Internet on the desktop, the ability to
> sync their experiences across these 2 devices can be very important
> and the use case of being able to log in with your ID into the
> browser on a shared computer and when you log off have that
> information on your mobile devices occurs more often and is more
> important that when people lose their phone or reset it, etc.
Very interesting! Have you looped this information back to the Product team? I don't think that's fully factored into the product plan, although signin-to-the-browser would certainly go a long way to achieving this.
> On 5/2/2012 1:59 PM, JP Rosevear wrote:
>> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
>>> I spoke with mccr8 and benm about fixing CC and GC pauses >>> specifically. We nomed a few bugs, which were triaged yesterday.
>>> I tend to agree with Taras' assertion about this being a non goal >>> but would reframe the assertion as this is not a measurable goal. We >>> can make general improvements but there is no way to know that we >>> have met this requirement. We can measure success and give people a >>> clear target if we rephrase the requirement as something like:
>>> Play a 10 minute video (default max length allowed on YouTube) >>> without noticeable pauses.
>>> Play game X for 10 minutes without noticeable pauses or skips (jank).
>>> Two notes:
>>> 1. We may need to specify hardware as older phones/machines will >>> likely have problems.
>>> 2. I don't know what to recommend for game X but I'm sure Martin >>> Best can make some suggestions.
>> The key question question is would these block. ie would k9o not
>> ship/be done without these. I suspect the answer is we would ship with
>> out big things like the js improvements.
> JP,
> I'm confused. Dmandelin worked through a bunch of JS bugs found the > ones he thought most pressing to give the most bang for the buck > performance-wise. If you would ship without something like that, what > *are* you shipping, quality wise?
What we have right now. The question is not whether these aren't good things to do (they obviously are). The question is whether they are *necessary* for this particular project of combining the identity and webapps and sync and B2G systems. If we would actually block shipping something because of GC pauses, then they are blockers. Otherwise, they are just important bugs.
> I've been thinking and asking about this one because it's the main
> goal that affects JS. Based on responses from Asa, Sheila, and Alex
> this morning, I just scoped our efforts in JS, narrowly, and +'d 3
> bugs. They form a coherent response that should greatly improve JS
> pauses, so that (plus bugs required to support Script Debugger) is
> our Kilimanjaro contribution.
I wanted to echo David here since games represent such a massive segment of the apps story. We really need to get the pauses under control to allow developers to produce product people will pay for. Especially in light of Chromes success in this area. To put a number on this, we should target getting the "hitching" time down to 16ms per second to make things work well. This represents about 1 frame lost per second. This should be a clear target for desktop but maybe harder to achieve on mobile. The more devices that will support this level of consistent frame rate the better off we will be.
> On 5/2/2012 10:37 PM, Clint Talbert wrote:
>> On 5/2/2012 1:59 PM, JP Rosevear wrote:
>>> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
>>>> I spoke with mccr8 and benm about fixing CC and GC pauses
>>>> specifically. We nomed a few bugs, which were triaged yesterday.
>>>> I tend to agree with Taras' assertion about this being a non goal
>>>> but would reframe the assertion as this is not a measurable goal. We
>>>> can make general improvements but there is no way to know that we
>>>> have met this requirement. We can measure success and give people a
>>>> clear target if we rephrase the requirement as something like:
>>>> Play a 10 minute video (default max length allowed on YouTube)
>>>> without noticeable pauses.
>>>> Play game X for 10 minutes without noticeable pauses or skips (jank).
>>>> Two notes:
>>>> 1. We may need to specify hardware as older phones/machines will
>>>> likely have problems.
>>>> 2. I don't know what to recommend for game X but I'm sure Martin
>>>> Best can make some suggestions.
>>> The key question question is would these block. ie would k9o not
>>> ship/be done without these. I suspect the answer is we would ship with
>>> out big things like the js improvements.
>> JP,
>> I'm confused. Dmandelin worked through a bunch of JS bugs found the
>> ones he thought most pressing to give the most bang for the buck
>> performance-wise. If you would ship without something like that, what
>> *are* you shipping, quality wise?
> What we have right now. The question is not whether these aren't good
> things to do (they obviously are). The question is whether they are
> *necessary* for this particular project of combining the identity and
> webapps and sync and B2G systems. If we would actually block shipping
> something because of GC pauses, then they are blockers. Otherwise, they
> are just important bugs.
The Product leads are not happy with the pauses that Apps are experiencing as a result of JS pauses. We should do what we can to fix that in the time we have available. Several bugs/features have been identified that we believe are important to k9o. We're calling these blockers.
If we get estimates back that say "we thought it was 5 weeks of work but it turns out to be a year" or we get close to the release and fixes are nowhere in sight, then we'll probably unblock on it because that's not a reasonable schedule and we'd rather get the rest of the good out there sooner than wait a year for one piece.
We've never had a release where we committed to and stuck with every bug/feature that was at one time marked a blocker and we don't have to start that now. We mark things blockers because we think without them we have a significantly less good release. Then we have to balance getting everything in to the release against slipping the and make some decisions. Sometimes we drop blockers and sometimes we slip the release.
Today these bugs are blockers. We think they will stay blockers and that we will get fixes in time for announcing k9o.
Also, not sure if it was an unintentional omission, but k9o also includes Desktop and Mobile. It's not just B2G, Apps, and Identity. (And it doesn't really include Sync, IMO.)
On Thursday, May 3, 2012 10:28:31 AM UTC-4, Benjamin Smedberg wrote:
> On 5/2/2012 10:37 PM, Clint Talbert wrote:
> > On 5/2/2012 1:59 PM, JP Rosevear wrote:
> >> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
> >>> I spoke with mccr8 and benm about fixing CC and GC pauses > >>> specifically. We nomed a few bugs, which were triaged yesterday.
> >>> I tend to agree with Taras' assertion about this being a non goal > >>> but would reframe the assertion as this is not a measurable goal. We > >>> can make general improvements but there is no way to know that we > >>> have met this requirement. We can measure success and give people a > >>> clear target if we rephrase the requirement as something like:
> >>> Play a 10 minute video (default max length allowed on YouTube) > >>> without noticeable pauses.
> >>> Play game X for 10 minutes without noticeable pauses or skips (jank).
> >>> Two notes:
> >>> 1. We may need to specify hardware as older phones/machines will > >>> likely have problems.
> >>> 2. I don't know what to recommend for game X but I'm sure Martin > >>> Best can make some suggestions.
> >> The key question question is would these block. ie would k9o not
> >> ship/be done without these. I suspect the answer is we would ship with
> >> out big things like the js improvements.
> > JP,
> > I'm confused. Dmandelin worked through a bunch of JS bugs found the > > ones he thought most pressing to give the most bang for the buck > > performance-wise. If you would ship without something like that, what > > *are* you shipping, quality wise?
> What we have right now. The question is not whether these aren't good > things to do (they obviously are). The question is whether they are > *necessary* for this particular project of combining the identity and > webapps and sync and B2G systems. If we would actually block shipping > something because of GC pauses, then they are blockers. Otherwise, they > are just important bugs.
> --BDS
So from a games perspective, this is a blocker. In fact it is the single most important blocker between us and product being sales worthy. How games fit in to the larger agenda is a question that is worth considering and maybe product can comment on this.
On Wednesday, May 2, 2012 4:59:34 PM UTC-4, JP Rosevear wrote:
> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
> > I spoke with mccr8 and benm about fixing CC and GC pauses specifically. We nomed a few bugs, which were triaged yesterday.
> > I tend to agree with Taras' assertion about this being a non goal but would reframe the assertion as this is not a measurable goal. We can make general improvements but there is no way to know that we have met this requirement. We can measure success and give people a clear target if we rephrase the requirement as something like:
> > Play a 10 minute video (default max length allowed on YouTube) without noticeable pauses.
> > Play game X for 10 minutes without noticeable pauses or skips (jank).
> > Two notes:
> > 1. We may need to specify hardware as older phones/machines will likely have problems.
> > 2. I don't know what to recommend for game X but I'm sure Martin Best can make some suggestions.
> The key question question is would these block. ie would k9o not
> ship/be done without these. I suspect the answer is we would ship with
> out big things like the js improvements.
> Thanks,
> -JP
I think the only bit I would see as blocking is the pausing or "hitching" problem. I know it may not seem like it but I have seen game projects fail when they couldn't eliminate inconstant frame rates on otherwise good games. The users just have a low tolerance for this particular issue. Otherwise many of the requirements for games are already landed or very close to it, so this is really the main hot button topic left for my perspective.
If the first products out the door on the app store fail to achieve financial success, it's going to be much harder to get that second wave of developers to jump in. I would have reservations about releasing without this issue improved.
Again, always take my feedback from the stand point that it really depends on how much games matter to the over all strategy. As they seem to be a dominate force on most App stores, I'm assuming they are pretty darn important.
On Thursday, May 3, 2012 2:02:02 PM UTC-4, Asa Dotzler wrote:
> On 5/3/2012 7:28 AM, Benjamin Smedberg wrote:
> > On 5/2/2012 10:37 PM, Clint Talbert wrote:
> >> On 5/2/2012 1:59 PM, JP Rosevear wrote:
> >>> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
> >>>> I spoke with mccr8 and benm about fixing CC and GC pauses
> >>>> specifically. We nomed a few bugs, which were triaged yesterday.
> >>>> I tend to agree with Taras' assertion about this being a non goal
> >>>> but would reframe the assertion as this is not a measurable goal. We
> >>>> can make general improvements but there is no way to know that we
> >>>> have met this requirement. We can measure success and give people a
> >>>> clear target if we rephrase the requirement as something like:
> >>>> Play a 10 minute video (default max length allowed on YouTube)
> >>>> without noticeable pauses.
> >>>> Play game X for 10 minutes without noticeable pauses or skips (jank).
> >>>> Two notes:
> >>>> 1. We may need to specify hardware as older phones/machines will
> >>>> likely have problems.
> >>>> 2. I don't know what to recommend for game X but I'm sure Martin
> >>>> Best can make some suggestions.
> >>> The key question question is would these block. ie would k9o not
> >>> ship/be done without these. I suspect the answer is we would ship with
> >>> out big things like the js improvements.
> >> JP,
> >> I'm confused. Dmandelin worked through a bunch of JS bugs found the
> >> ones he thought most pressing to give the most bang for the buck
> >> performance-wise. If you would ship without something like that, what
> >> *are* you shipping, quality wise?
> > What we have right now. The question is not whether these aren't good
> > things to do (they obviously are). The question is whether they are
> > *necessary* for this particular project of combining the identity and
> > webapps and sync and B2G systems. If we would actually block shipping
> > something because of GC pauses, then they are blockers. Otherwise, they
> > are just important bugs.
> The Product leads are not happy with the pauses that Apps are > experiencing as a result of JS pauses. We should do what we can to fix > that in the time we have available. Several bugs/features have been > identified that we believe are important to k9o. We're calling these > blockers.
> If we get estimates back that say "we thought it was 5 weeks of work but > it turns out to be a year" or we get close to the release and fixes are > nowhere in sight, then we'll probably unblock on it because that's not a > reasonable schedule and we'd rather get the rest of the good out there > sooner than wait a year for one piece.
> We've never had a release where we committed to and stuck with every > bug/feature that was at one time marked a blocker and we don't have to > start that now. We mark things blockers because we think without them we > have a significantly less good release. Then we have to balance getting > everything in to the release against slipping the and make some > decisions. Sometimes we drop blockers and sometimes we slip the release.
> Today these bugs are blockers. We think they will stay blockers and that > we will get fixes in time for announcing k9o.
> Also, not sure if it was an unintentional omission, but k9o also > includes Desktop and Mobile. It's not just B2G, Apps, and Identity. (And > it doesn't really include Sync, IMO.)
> - A
I agree with everything Asa mentions here. Part of the reason I propose this is to highlight the importance. Another is that, via conversations with David Mandelin it seems to be within reach via IGC and fixes to recompilation. There is no way to know for sure if the current work will be the final piece needed to reduce this issue enough to make it considered resolved. My goal is to have the needed people able to focus this issue rather than work on P1s that are considered 100% blockers. So I guess the point is that we need to do everything we can to solve it, but if we can't and it will be a year to fix, we would ship with it as is.
On Thursday, May 3, 2012 2:02:02 PM UTC-4, Asa Dotzler wrote:
> On 5/3/2012 7:28 AM, Benjamin Smedberg wrote:
> > On 5/2/2012 10:37 PM, Clint Talbert wrote:
> >> On 5/2/2012 1:59 PM, JP Rosevear wrote:
> >>> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
> >>>> I spoke with mccr8 and benm about fixing CC and GC pauses
> >>>> specifically. We nomed a few bugs, which were triaged yesterday.
> >>>> I tend to agree with Taras' assertion about this being a non goal
> >>>> but would reframe the assertion as this is not a measurable goal. We
> >>>> can make general improvements but there is no way to know that we
> >>>> have met this requirement. We can measure success and give people a
> >>>> clear target if we rephrase the requirement as something like:
> >>>> Play a 10 minute video (default max length allowed on YouTube)
> >>>> without noticeable pauses.
> >>>> Play game X for 10 minutes without noticeable pauses or skips (jank).
> >>>> Two notes:
> >>>> 1. We may need to specify hardware as older phones/machines will
> >>>> likely have problems.
> >>>> 2. I don't know what to recommend for game X but I'm sure Martin
> >>>> Best can make some suggestions.
> >>> The key question question is would these block. ie would k9o not
> >>> ship/be done without these. I suspect the answer is we would ship with
> >>> out big things like the js improvements.
> >> JP,
> >> I'm confused. Dmandelin worked through a bunch of JS bugs found the
> >> ones he thought most pressing to give the most bang for the buck
> >> performance-wise. If you would ship without something like that, what
> >> *are* you shipping, quality wise?
> > What we have right now. The question is not whether these aren't good
> > things to do (they obviously are). The question is whether they are
> > *necessary* for this particular project of combining the identity and
> > webapps and sync and B2G systems. If we would actually block shipping
> > something because of GC pauses, then they are blockers. Otherwise, they
> > are just important bugs.
> The Product leads are not happy with the pauses that Apps are > experiencing as a result of JS pauses. We should do what we can to fix > that in the time we have available. Several bugs/features have been > identified that we believe are important to k9o. We're calling these > blockers.
> If we get estimates back that say "we thought it was 5 weeks of work but > it turns out to be a year" or we get close to the release and fixes are > nowhere in sight, then we'll probably unblock on it because that's not a > reasonable schedule and we'd rather get the rest of the good out there > sooner than wait a year for one piece.
> We've never had a release where we committed to and stuck with every > bug/feature that was at one time marked a blocker and we don't have to > start that now. We mark things blockers because we think without them we > have a significantly less good release. Then we have to balance getting > everything in to the release against slipping the and make some > decisions. Sometimes we drop blockers and sometimes we slip the release.
> Today these bugs are blockers. We think they will stay blockers and that > we will get fixes in time for announcing k9o.
> Also, not sure if it was an unintentional omission, but k9o also > includes Desktop and Mobile. It's not just B2G, Apps, and Identity. (And > it doesn't really include Sync, IMO.)
> - A
On Thursday, May 3, 2012 2:02:02 PM UTC-4, Asa Dotzler wrote:
> On 5/3/2012 7:28 AM, Benjamin Smedberg wrote:
> > On 5/2/2012 10:37 PM, Clint Talbert wrote:
> >> On 5/2/2012 1:59 PM, JP Rosevear wrote:
> >>> On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
> >>>> I spoke with mccr8 and benm about fixing CC and GC pauses
> >>>> specifically. We nomed a few bugs, which were triaged yesterday.
> >>>> I tend to agree with Taras' assertion about this being a non goal
> >>>> but would reframe the assertion as this is not a measurable goal. We
> >>>> can make general improvements but there is no way to know that we
> >>>> have met this requirement. We can measure success and give people a
> >>>> clear target if we rephrase the requirement as something like:
> >>>> Play a 10 minute video (default max length allowed on YouTube)
> >>>> without noticeable pauses.
> >>>> Play game X for 10 minutes without noticeable pauses or skips (jank).
> >>>> Two notes:
> >>>> 1. We may need to specify hardware as older phones/machines will
> >>>> likely have problems.
> >>>> 2. I don't know what to recommend for game X but I'm sure Martin
> >>>> Best can make some suggestions.
> >>> The key question question is would these block. ie would k9o not
> >>> ship/be done without these. I suspect the answer is we would ship with
> >>> out big things like the js improvements.
> >> JP,
> >> I'm confused. Dmandelin worked through a bunch of JS bugs found the
> >> ones he thought most pressing to give the most bang for the buck
> >> performance-wise. If you would ship without something like that, what
> >> *are* you shipping, quality wise?
> > What we have right now. The question is not whether these aren't good
> > things to do (they obviously are). The question is whether they are
> > *necessary* for this particular project of combining the identity and
> > webapps and sync and B2G systems. If we would actually block shipping
> > something because of GC pauses, then they are blockers. Otherwise, they
> > are just important bugs.
> The Product leads are not happy with the pauses that Apps are > experiencing as a result of JS pauses. We should do what we
> On 02/05/2012 17:18 PM, Robert Kaiser wrote:
>> Ragavan Srinivasan schrieb:
>>> * there really is not a big market for Android tablets
>> That tablet market surely isn't really large, that's true, but among
>> tablets,
>> Android has ~40% (and growing) market share, so it's not as negligible
>> as you
>> may make it sound. The iPad still has ~60% (trending down), but it's
>> by far not
>> like the tablet market would be all Apple and marginally Android.
> Out of interest, where do those numbers come from? They do not reflect
> what I see on my daily commute (but that sample may be poorly selected!).
