On Friday 2016-05-13 13:10 -0700, Andrew McCreight wrote:
> On 64-bit systems, pointers take 8 bytes of memory instead of 4. A lot of
> the contents of memory is pointers. Thus a 64-bit build consumes more
> memory for a given workload. It isn't as bad as, say, twice as much memory,
> but it is eno
Since we didn't require SSE2 in 32-bit builds until this point, were
floating-point results rounded unpredictably in those builds until now?
On Fri, May 13, 2016 at 1:42 PM, Benjamin Smedberg
wrote:
> I am talking about requiring SSE2. That is a larger (but still quite small)
> population, but
The actual content of the page is not final, but I did include that
recommendation in my request for a SUMO page. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1270221
--BDS
On Fri, May 13, 2016 at 4:59 PM, Adam Roach wrote:
> On 5/13/16 14:26, Ben Hearsum wrote:
>
>> I intend to make sure t
On 5/13/16 14:26, Ben Hearsum wrote:
I intend to make sure that Beta/Release/ESR is configured in such a
way that users get the most up to date release possible. Eg: serve
10.6-10.8 users the latest 48.0 point release, then give them a
deprecation notice.
Presumably, the deprecation notice w
I am talking about requiring SSE2. That is a larger (but still quite small)
population, but the upside of being able to turn on SSE2 optimizations by
default is an important benefit. I've discussed and confirmed this with
Firefox product management.
So yes, the plan of record is to require SSE2 st
We have considered this, but in the grand rollout plans for 64-bit Firefox
it's low on the list. We're still dealing with Flash sandboxing/functional
regressions as a blocker for wider rollout, and the next step is probably
to progressively roll out win64 to new users before we consider anything
fo
I didn't know we intended to drop support in 48. I just assumed 49 from
reading the blog post and knowing that things were just landing in nightly.
At this point, though, I don't want to do uplifts and would prefer that
this ride the 49 train.
--BDS
On Fri, May 13, 2016 at 3:24 PM, Ben Hearsum w
On Fri, May 13, 2016 at 1:02 PM, wrote:
> Why do you developers keep insisting breathlessly that 64-bit builds are
> memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have
> a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think
> that I use Firefox close
On Friday, May 13, 2016 at 7:35:52 AM UTC-5, Ben Hearsum wrote:
> On 2016-05-12 06:44 PM, khagar...@gmail.com wrote:
> > On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote:
> >> Lawrence Mandel writes:
> >>
> >>> Do we need this criteria?
> >>>
> >>> RAM - Does it hurt to move an
Yes. The intention was 48.0. Given that that doesn't actually buy us
anything at this point, dropping support in 49.0 is fine.
Lawrence
On Fri, May 13, 2016 at 3:24 PM, Ben Hearsum wrote:
> Thanks for clarifying. It seems like the confusion came from the fact that
> we had *intended* to drop su
This was discussed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1269811#c7. It's
technically possible to do, but it didn't seem worthwhile on Nightly and
Aurora.
I intend to make sure that Beta/Release/ESR is configured in such a way
that users get the most up to date release possible. Eg:
Thanks for clarifying. It seems like the confusion came from the fact
that we had *intended* to drop support in 48.0, but it hadn't happened
yet. And now we don't *intend* to drop support until 49.0?
On 2016-05-13 02:55 PM, Benjamin Smedberg wrote:
Right now the code to disable 10.6 has landed
Nils, feel free to file a bug on this and cc bhearsum. I don't know how
much work this would be.
--BDS
On Fri, May 13, 2016 at 2:18 PM, Nils Ohlmeier
wrote:
>
> > On May 3, 2016, at 15:18, Adam Roach wrote:
> >
> > On 5/3/16 4:59 PM, Justin Dolske wrote:
> >> On 5/3/16 12:21 PM, Gregory Szorc
Right now the code to disable 10.6 has landed only on nightly/49, and other
bits are still blocked (see bug 1270217) because our MacOS builders (not
the testers) are still running MacOS 10.7. As of this point, I expect that
Firefox 48 will still run on 10.6-10.8 and the first release to drop
suppor
> On May 10, 2016, at 19:58, Lawrence Mandel wrote:
>
> The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7,
> and 10.8 in August, 2016." This means that we will end support with the
> Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.
Why do Firefox DevEd
> On May 3, 2016, at 15:18, Adam Roach wrote:
>
> On 5/3/16 4:59 PM, Justin Dolske wrote:
>> On 5/3/16 12:21 PM, Gregory Szorc wrote:
>>
>>> * The update server has been reconfigured to not serve Nightly updates to
>>> 10.6-10.8 (bug 1269811)
>>
>> Are we going to be showing some kind of notic
On Fri, May 13, 2016 at 11:07 AM, Chris AtLee wrote:
> I'm very happy to let you know that we've recently started running some of
> our Windows 7 tests in AWS. Currently we're running these suites in Amazon
> for all branches of gecko 49 and higher:
> * Web platform tests + reftests
> * gtest
> *
I'm very happy to let you know that we've recently started running some of
our Windows 7 tests in AWS. Currently we're running these suites in Amazon
for all branches of gecko 49 and higher:
* Web platform tests + reftests
* gtest
* cppunit
* jittest
* jsreftest
* crashtest
Since these are now wor
On 05/13/2016 10:49 AM, Jet Villegas wrote:
> If I'm reading the dependency list correctly, we still plan to uplift to
> 48 if we can get bug 1264905 fixed in time. Is that correct?
bug 1264905's fix (a pref-unguarding) was just landed, as well.
We could uplift both, if we *also* uplift bug 12699
If I'm reading the dependency list correctly, we still plan to uplift to 48
if we can get bug 1264905 fixed in time. Is that correct?
--Jet
On Fri, May 13, 2016 at 10:15 AM, Daniel Holbert
wrote:
> On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> > Estimated or target release:
> > Firefox 46 (
On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> Estimated or target release:
> Firefox 46 (current Nightly), or 47 if we need to hold it back a
> release to fix things.
>
> Preference behind which this will be implemented:
> layout.css.prefixes.webkit
Following up on this -- this feature will
On 5/12/16 7:26 PM, Mike Taylor wrote:
On 5/12/16 2:48 PM, Jan-Ivar Bruaroey wrote:
Our original intent behind those choices was to let users join a video
conference as an "audio only" participant. Unfortunately, sites don't
expect this behavior and often don't work right when the track is
miss
On 2016-05-12 06:44 PM, khagar...@gmail.com wrote:
On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote:
Lawrence Mandel writes:
Do we need this criteria?
RAM - Does it hurt to move an instance that has <4GB?
Yes. OOM will be more common with 64-bit builds on systems with
l
On Thursday, May 12, 2016 at 5:44:32 PM UTC-5, khag...@gmail.com wrote:
> On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote:
> > Lawrence Mandel writes:
> >
> > > Do we need this criteria?
> > >
> > > RAM - Does it hurt to move an instance that has <4GB?
> >
> > Yes. OOM will
On Thursday, 12 May 2016 21:36:53 UTC+1, Chris Peterson wrote:
> Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit
> Firefox. Streaming video services will likely move their Firefox users
> from Silverlight to Widevine this year, so Silverlight usage will
> decline by EOY.
25 matches
Mail list logo
