On Tue, Sep 15, 2015 at 6:32 PM, Naoki Hirata <[email protected]> wrote: > > I believe we still do care. > > Running Engineering build will make some difference as the 319 MB takes into > account the camera but not Marionette (adb + devtools) which the engineering > build runs. > > Having said that we run automation tests through jenkins, I'll check with > mwargers in regards to the issue to see if he already filed a bug or not.
Yes, we're running the Gaia UI tests with the 319MB configuration and we have various tests that are failing (intermittently) and disabled because they just don't work with 319MB: 1172167 [Flame][Cards View] Cards view loses the list of recently opened apps 1176502 Failure in test_homescreen_column_layout.py on the Flame device, because Settings app gets killed 1178859 test_browser_bookmark.py: "IOError: Connection to Marionette server is lost." 1181344 [Window Management] Settings will be a blank white screen when returning from the "Built-in Keyboard" settings 1188080 test_rocketbar_offline_behavior.py: "NoSuchWindowException: None" 1189262 Failure in test_browser_share_link.py using Flame 319MB 1204280 [Flame] Intermittent failure in test_sms_contact.py in tap_send_sms using Flame 319MB 1188603 [Settings][Ringtones] Share activity closes when attempting to add custom ringtone I think these bugs need to be fixed, because they stand for lost functionality in those low memory conditions. All the bugs currently out there, regarding supporting 319MB memory configuration: https://bugzilla.mozilla.org/buglist.cgi?list_id=12549261&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=[319MB-Flame-Support] Regards, Martijn > > > We still have not resolved the series of initial bugs going into 2.5/3.0: > https://bugzilla.mozilla.org/show_bug.cgi?id=1155854 > https://bugzilla.mozilla.org/show_bug.cgi?id=1162535 > > On Tue, Sep 15, 2015 at 2:13 AM, Ting-Yu Chou <[email protected]> wrote: >> >> A bit off-topic. >> >> Raptor [1] just records a serious memory regression though, not sure is it >> related to the issue you see. >> >> Ting >> >> [1] >> http://raptor.mozilla.org/#/dashboard/script/apps-memory.js?device=flame-kk&branch=master&memory=319 >> >> On Tue, Sep 15, 2015 at 4:56 PM, Gabriele Svelto <[email protected]> wrote: >>> >>> I was doing some testing in the past few days on a Flame using the >>> 319MiB memory switch and found that our core apps are now almost >>> unusable on it. Opening a single app seems to end up killing the >>> homescreen and keeping two open at the same time is almost impossible. >>> >>> So I've got two questions: the first one is, did we significantly >>> regress memory consumption again? Or is it just gecko having grown >>> significantly in the past few weeks making our minimum process size >>> larger? The second question is obviously: do we still care about 256MiB >>> devices? Because if we still do then it looks like we're not in a good >>> spot for a 2.5 release running on those. If we don't care I suppose it's >>> fine though we should still keep our memory consumption under control. >>> If we move our minimum to 512MiB we'll have plenty of room and this >>> might cause us to regress even further almost without noticing (*). >>> >>> I'm running an engineering build BTW, but I don't think this should make >>> much of a difference. >>> >>> Gabriele >>> >>> *) Unless the screen has a rather high resolution, in which case 512MiB >>> might still yield only a small amount of usable memory for apps as most >>> of it will go to the framebuffer and accompanying structures (layers & co). >>> >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-fxos >>> >> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
