Re: 64-bit Firefox progress report: 2017-07-18

On 2017-07-19 10:18 AM, Mike Hoye wrote: On 2017-07-19 3:58 AM, Chris Peterson wrote: On 2017-07-19 12:01 AM, Mike Hommey wrote: What's the plan for eligible people that still want to keep 32-bit Firefox? Outside of our QA team (or others orgs, I guess?) do we have a set of use cases that

64-bit Firefox progress report: 2017-07-18

We are on track to make 64-bit Firefox the default build for Win64 OS, bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox users running Win64. PLANS: * In Firefox 55 (August 8), the Windows stub installer will default to 64-bit Firefox for eligible users (Win64 and 2+

Re: 64-bit Firefox progress report: 2017-07-18

On Tue, Jul 18, 2017 at 11:38:56PM -0700, Chris Peterson wrote: > We are on track to make 64-bit Firefox the default build for Win64 OS, > bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox > users running Win64. > > PLANS: > > * In Firefox 55 (August 8), the Windows stub

Re: 64-bit Firefox progress report: 2017-07-18

On 2017-07-19 12:01 AM, Mike Hommey wrote: What's the plan for eligible people that still want to keep 32-bit Firefox? Are they going to have to stop auto upgrades, which would get them automatically on 64-bits and upgrade manually? This is especially going to be a problem for users with less

Re: Phabricator Update, July 2017

>On 7/13/17 9:04 PM, Mark Côté wrote: >> It is also what newer systems >> do today (e.g. GitHub and the full Phabricator suite) > >I should note that with GitHub what this means is that you get discussion >on the PR that should have gone in the issue, with the result that people >following the

Firefox data platform & tools update, Q2 2017

The data platform and tools teams are working on our core Telemetry system, the data pipeline, providing core datasets and maintaining some central data viewing tools. To make new work more visible, we provide quarterly updates. What’s new in the last few months? A lot of work in the last months

Re: 64-bit Firefox progress report: 2017-07-18

On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote: > On Jul 19, 2017 6:20 PM, "Mike Hommey" wrote: > > > What would be the rationale behind this choice? > > Smaller memory footprint, which, you'll admit, when you're on a machine > with (less than) 2GB RAM, makes a

Re: 64-bit Firefox progress report: 2017-07-18

On Jul 19, 2017 8:57 PM, "Mike Hommey" wrote: On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote: > On Jul 19, 2017 6:20 PM, "Mike Hommey" wrote: > > > What would be the rationale behind this choice? > > Smaller memory footprint, which, you'll admit,

Re: Phabricator Update, July 2017

>On 2017-07-14 1:31 AM, Jim Blandy wrote: >> Many people seem to be asking, essentially: What will happen to old bugs? >> I'm trying to follow the discussion, and I'm not clear on this myself. >> >> For example, "Splinter will be turned off." For commenting and reviewing, >> okay, understood. What

Re: 64-bit Firefox progress report: 2017-07-18

On Thu, Jul 20, 2017 at 12:01:04AM +0200, Jean-Yves Avenard wrote: > Hi > > On Wed, Jul 19, 2017 at 9:01 AM, Mike Hommey wrote: > > What's the plan for eligible people that still want to keep 32-bit > > Firefox? Are they going to have to stop auto upgrades, which would get > >

Re: 64-bit Firefox progress report: 2017-07-18

On 2017-07-19 3:58 AM, Chris Peterson wrote: On 2017-07-19 12:01 AM, Mike Hommey wrote: What's the plan for eligible people that still want to keep 32-bit Firefox? Outside of our QA team (or others orgs, I guess?) do we have a set of use cases that would motivate people to flip that switch?

Re: removing "the old way" of signing add-ons

On 7/19/2017 4:06 PM, David Keeler wrote: [dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on dev-platform] ... Given all this, the question is do we still need this second API? Does Thunderbird or SeaMonkey use it for any reason, or can we simplify the code-base, reduce

Re: removing "the old way" of signing add-ons

On Wed, Jul 19, 2017 at 05:02:23PM -0700, R Kent James wrote: On 7/19/2017 4:06 PM, David Keeler wrote: [dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on dev-platform] ... Given all this, the question is do we still need this second API? Does Thunderbird or SeaMonkey

Re: removing "the old way" of signing add-ons

On Wed, Jul 19, 2017 at 5:02 PM, R Kent James wrote: > On 7/19/2017 4:06 PM, David Keeler wrote: > >> [dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on >> dev-platform] >> > ... > >> Given all this, the question is do we still need this second API? Does >>

Re: 64-bit Firefox progress report: 2017-07-18

On Jul 19, 2017 6:20 PM, "Mike Hommey" wrote: > What would be the rationale behind this choice? Smaller memory footprint, which, you'll admit, when you're on a machine with (less than) 2GB RAM, makes a difference. I thought we had data that showed OOM (small) due to VM

Re: 64-bit Firefox progress report: 2017-07-18

On Wed, Jul 19, 2017 at 09:40:12PM -0400, Ben Kelly wrote: > On Jul 19, 2017 8:57 PM, "Mike Hommey" wrote: > > On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote: > > On Jul 19, 2017 6:20 PM, "Mike Hommey" wrote: > > > > > What would be the rationale

removing "the old way" of signing add-ons

[dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on dev-platform] Hello Everyone, You may or may not be surprised to learn that Gecko contains two different ways to verify that an add-on has been signed. The primary method is nsIX509CertDB.openSignedAppFileAsync. This is