Re: Requiring secure contexts for new features

[Jonathan Kingston]

> One potential resolution to that sort of problem is to ship in secure
contexts anyway and ask other browsers to do the same.

It would be really great from a HTTPS adoption standpoint if we can hold
back as many features from being shipped to insecure contexts.

Perhaps Firefox could ship new features to HTTPS and provide prefs to
enable to insecure, which would allow flexibility for webcompat if we
needed to change the stance in stable.

Could we have a process to handle when to withhold these incompatibilities
from insecure contexts?

On Tue, Jan 16, 2018 at 11:02 PM, Martin Thomson  wrote:

> Great news.  Thanks to all those involved for getting to this point.
>
> Anne, your posting suggests an exception is likely if:
>
> * other browsers already ship the feature insecurely
> * it can be demonstrated that requiring secure contexts results in
> undue implementation complexity.
>
> Either of these criteria are sufficient, right?  However, I expect
> that we'll want to hold the line in some cases where other browsers
> ship anyway.  How do we plan to resolve that?  One potential
> resolution to that sort of problem is to ship in secure contexts
> anyway and ask other browsers to do the same.
>
> My expectation is that we'll discuss these and exercise judgment.  But
> I thought that I'd raise this point here.  I want to avoid creating an
> expectation here that we're happy with lowest common denominator when
> it comes to these issues.
>
> On Wed, Jan 17, 2018 at 5:11 AM, Anne van Kesteren 
> wrote:
> > Yesterday Mozilla announced Firefox will be restricting new features
> > to secure contexts (i.e., HTTPS):
> >
> >   https://blog.mozilla.org/security/2018/01/15/secure-
> contexts-everywhere/
> >
> > I'm glad to report that thus far this has been very well received.
> >
> > I'm posting this here per suggestion from Ben Kelly and because:
> >
> > * Not all module owners and peers might have seen the blog post and
> > this might impact them if their module currently, or in the future,
> > exposes features to web content.
> > * Modules might want to look into ways of enforcing this
> > programmatically, to ease ongoing maintenance and guide everyone to do
> > the right thing without having to ask/review/etc. E.g.,
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
> > for enforcement around our bindings.
> > * Mozillians might have questions not addressed in the post and this
> > seems like a good place to centralize those and address them.
> >
> > Insofar as documenting this policy elsewhere goes I've updated
> > https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
> > update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
> > manner. (The latter will probably also need to be generalized as
> > currently it suggests it's for APIs only.)
> >
> > Hope that helps,
> >
> >
> > --
> > https://annevankesteren.nl/
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: remote jar: protocol pref

[Gijs Kruitbosch]

On 17/01/2018 00:01, Daniel Veditz wrote:

On Fri, Jan 12, 2018 at 2:12 PM, Gijs Kruitbosch 
wrote:


the most likely group of people to have enabled this (given 0 public
reports on breakage so far, as far as I'm aware) are people on ESR or
otherwise in enterprise environments



​Or those trying to run multi-file testcases packaged as a ZIP archive on
bugzilla (Hi!) without having to run a localhost server for it. Especially
handy when the testcase was demonstrating something specifically about our
handling of https pages.


Yes, I'm aware of this issue and mentioned it on the bug. You're not the 
only one who does this.



Does removing this let us remove a good chunk of code?


I am led to believe that the answer to this is 'yes'.


I'm glad it's
disabled by default (attack surface reduction) but afaik we still have to
support jar: internally.


At this point I am actually not aware of any substantial consumers who 
rely on jar: explicitly internally through gecko (Android has some 
consumers that go through java, but that's not the same, see comments on 
the bug). chrome: and resource: of course do so implicitly, but we 
don't, as a rule, e.g. load documents with jar: URIs. So "support" is 
relative.



It may be just me using this at this point so if
we can kill a bunch of stuff that's a win, but if you're just taking away
the pref is that worth it?


Even if it was mostly the pref, it removes complexity and edgecases, and 
I think that's something we should push for as we add complexity 
elsewhere, to keep things reasonable, as it were. :-)


If "archives on bugzilla" is a significant thing, we should push for 
better support from bugzilla. (Also for other formats like gz, bz2, rar, 
etc. which jar: doesn't support!)


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: remote jar: protocol pref

[Daniel Veditz]

On Fri, Jan 12, 2018 at 2:12 PM, Gijs Kruitbosch 
wrote:

> the most likely group of people to have enabled this (given 0 public
> reports on breakage so far, as far as I'm aware) are people on ESR or
> otherwise in enterprise environments
>

​Or those trying to run multi-file testcases packaged as a ZIP archive on
bugzilla (Hi!) without having to run a localhost server for it. Especially
handy when the testcase was demonstrating something specifically about our
handling of https pages.

Does removing this let us remove a good chunk of code? I'm glad it's
disabled by default (attack surface reduction) but afaik we still have to
support jar: internally. It may be just me using this at this point so if
we can kill a bunch of stuff that's a win, but if you're just taking away
the pref is that worth it?

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Gregory Szorc]

On Tue, Jan 16, 2018 at 1:42 PM, Ted Mielczarek  wrote:

> On Tue, Jan 16, 2018, at 10:51 AM, Jean-Yves Avenard wrote:
> > Sorry for resuming an old thread.
> >
> > But I would be interested in knowing how long that same Lenovo P710
> > takes to compile *today*….> In the past 6 months, compilation times have
> certainly increased
> > massively.>
> > Anyhow, I’ve received yesterday the iMac Pro I ordered early December.
> > It’s a 10 cores Xeon-W (W-2150B) with 64GB RAM>
> > Here are the timings I measured, in comparison with the Mac Pro 2013 I
> > have (which until today was the fastest machines I had ever used)>
> > macOS 10.13.2:
> > Mac Pro late 2013 : 13m25s
> > iMac Pro : 7m20s
> >
> > Windows 10 fall creator
> > Mac Pro late 2013 : 24m32s (was 16 minutes less than a year ago!)
> > iMac Pro : 14m07s (16m10s with windows defender going)
> >
> > Interestingly, I can almost no longer get any benefits when using
> > icecream, with 36 cores it saves 11s, with 52 cores it saves 50s only…>
> > It’s a very sweet machine indeed
>
> I just did a couple of clobber builds against the tip of central
> (9be7249e74fd) on my P710 running Windows 10 Fall Creators Update
> and they took about 22 minutes each. Definitely slower than it
> used to be :-/
>
>
On an EC2 c5.17xlarge (36+36 CPUs) running Ubuntu 17.10 and using Clang
5.0, 9be7249e74fd does a clobber but configured `mach build` in 7:34. Rust
is very obviously the long pole in this build, with C++ compilation (not
linking) completing in ~2 minutes.

If I enable sccache for just Rust by setting "mk_add_options "export
RUSTC_WRAPPER=sccache" in my mozconfig, a clobber build with populated
cache for Rust completes in 3:18. And Rust is still the long pole -
although only by a few seconds. It's worth noting that CPU time for this
build remains in the same ballpark. But overall CPU utilization increases
from ~28% to ~64%. There's still work to do improving the efficiency of the
overall build system. But these are mostly in parts only touched by clobber
builds. If you do `mach build binaries` after touching compiled code, our
CPU utilization is terrific.

From a build system perspective, C/C++ scales up to dozens of cores just
fine (it's been this way for a few years). Rust is becoming a longer and
longer long tail (assuming you have enough CPU cores that the vast amount
of C/C++ completes before Rust does).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring secure contexts for new features

[Martin Thomson]

Great news.  Thanks to all those involved for getting to this point.

Anne, your posting suggests an exception is likely if:

* other browsers already ship the feature insecurely
* it can be demonstrated that requiring secure contexts results in
undue implementation complexity.

Either of these criteria are sufficient, right?  However, I expect
that we'll want to hold the line in some cases where other browsers
ship anyway.  How do we plan to resolve that?  One potential
resolution to that sort of problem is to ship in secure contexts
anyway and ask other browsers to do the same.

My expectation is that we'll discuss these and exercise judgment.  But
I thought that I'd raise this point here.  I want to avoid creating an
expectation here that we're happy with lowest common denominator when
it comes to these issues.

On Wed, Jan 17, 2018 at 5:11 AM, Anne van Kesteren  wrote:
> Yesterday Mozilla announced Firefox will be restricting new features
> to secure contexts (i.e., HTTPS):
>
>   https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
>
> I'm glad to report that thus far this has been very well received.
>
> I'm posting this here per suggestion from Ben Kelly and because:
>
> * Not all module owners and peers might have seen the blog post and
> this might impact them if their module currently, or in the future,
> exposes features to web content.
> * Modules might want to look into ways of enforcing this
> programmatically, to ease ongoing maintenance and guide everyone to do
> the right thing without having to ask/review/etc. E.g.,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
> for enforcement around our bindings.
> * Mozillians might have questions not addressed in the post and this
> seems like a good place to centralize those and address them.
>
> Insofar as documenting this policy elsewhere goes I've updated
> https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
> update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
> manner. (The latter will probably also need to be generalized as
> currently it suggests it's for APIs only.)
>
> Hope that helps,
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[smaug]

On 01/16/2018 11:41 PM, Mike Hommey wrote:

On Tue, Jan 16, 2018 at 10:02:12AM -0800, Ralph Giles wrote:

On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard 
wrote:

But I would be interested in knowing how long that same Lenovo P710 takes

to compile *today*….



On my Lenovo P710 (2x2x6 core Xeon E5-2643 v4), Fedora 27 Linux

debug -Og build with gcc: 12:34
debug -Og build with clang: 12:55
opt build with clang: 11:51

Interestingly, I can almost no longer get any benefits when using icecream,

with 36 cores it saves 11s, with 52 cores it saves 50s only…



Are you staturating all 52 cores during the buidls? Most of the increase in
build time is new Rust code, and icecream doesn't distribute Rust. So in
addition to some long compile times for final crates limiting the minimum
build time, icecream doesn't help much in the run-up either. This is why
I'm excited about the distributed build feature we're adding to sccache.


Distributed compilation of rust won't help unfortunately. That won't
solve the fact that the long pole of rust compilation is a series of
multiple long single-threaded processes that can't happen in parallel
because each of them depends on the output of the previous one.

Mike



Distributed compilation won't also help those remotees who may not have 
machines to setup
icecream or distributed sscache.
(I just got a new laptop because of rust compilation being so slow. )
I'm hoping rust compiler gets some heavy optimizations itself.


-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ted Mielczarek]

On Tue, Jan 16, 2018, at 10:51 AM, Jean-Yves Avenard wrote:
> Sorry for resuming an old thread.
> 
> But I would be interested in knowing how long that same Lenovo P710
> takes to compile *today*….> In the past 6 months, compilation times have 
> certainly increased
> massively.> 
> Anyhow, I’ve received yesterday the iMac Pro I ordered early December.
> It’s a 10 cores Xeon-W (W-2150B) with 64GB RAM> 
> Here are the timings I measured, in comparison with the Mac Pro 2013 I
> have (which until today was the fastest machines I had ever used)> 
> macOS 10.13.2:
> Mac Pro late 2013 : 13m25s
> iMac Pro : 7m20s
> 
> Windows 10 fall creator
> Mac Pro late 2013 : 24m32s (was 16 minutes less than a year ago!)
> iMac Pro : 14m07s (16m10s with windows defender going)
> 
> Interestingly, I can almost no longer get any benefits when using
> icecream, with 36 cores it saves 11s, with 52 cores it saves 50s only…> 
> It’s a very sweet machine indeed

I just did a couple of clobber builds against the tip of central
(9be7249e74fd) on my P710 running Windows 10 Fall Creators Update
and they took about 22 minutes each. Definitely slower than it
used to be :-/
-Ted


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Mike Hommey]

On Tue, Jan 16, 2018 at 10:02:12AM -0800, Ralph Giles wrote:
> On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard 
> wrote:
> 
> But I would be interested in knowing how long that same Lenovo P710 takes
> > to compile *today*….
> >
> 
> On my Lenovo P710 (2x2x6 core Xeon E5-2643 v4), Fedora 27 Linux
> 
> debug -Og build with gcc: 12:34
> debug -Og build with clang: 12:55
> opt build with clang: 11:51
> 
> Interestingly, I can almost no longer get any benefits when using icecream,
> > with 36 cores it saves 11s, with 52 cores it saves 50s only…
> >
> 
> Are you staturating all 52 cores during the buidls? Most of the increase in
> build time is new Rust code, and icecream doesn't distribute Rust. So in
> addition to some long compile times for final crates limiting the minimum
> build time, icecream doesn't help much in the run-up either. This is why
> I'm excited about the distributed build feature we're adding to sccache.

Distributed compilation of rust won't help unfortunately. That won't
solve the fact that the long pole of rust compilation is a series of
multiple long single-threaded processes that can't happen in parallel
because each of them depends on the output of the previous one.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Jean-Yves Avenard]

> On 16 Jan 2018, at 8:19 pm, Jean-Yves Avenard  wrote:
> 
> 
> 
>> On 16 Jan 2018, at 7:02 pm, Ralph Giles > > wrote:
>> 
>> On my Lenovo P710 (2x2x6 core Xeon E5-2643 v4), Fedora 27 Linux
>> 
>> debug -Og build with gcc: 12:34
>> debug -Og build with clang: 12:55
>> opt build with clang: 11:51
> 
> I didn’t succeed in booting linux unfortunately. so I can’t compare…
> 12 minutes sounds rather long, it’s about what the macpro is currently doing. 
> I typically get compilation times similar to mac…

so I didn’t manage to get linux to boot (tried all known main distributions)

But I ran a compilation inside VMWare on Mac, allocating “only” 16 cores as 
that’s the maximum and 32GB of RAM, it took 13m51s

No doubt it would go much lower once I manage to boot linux.

Damn fast machine !

JY

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Gregory Szorc]

Yes, most of the build time regressions in 2017 came from Rust. Leaning
more heavily on C++ features that require more processing or haven't been
optimized as much as C++ features that have been around for years is likely
also contributing.

Enabling sccache allows Rust compilations to be cached, which makes things
much faster on subsequent builds (since many Rust crates don't change that
often - but a few "large" crates like style do need to rebuild
semi-frequently).

We'll be transitioning workstations to the i9's because they are faster,
cheaper, and have more cores than the Xeons. But if you insist on having
ECC memory, you can still get the dual socket Xeons.

Last I heard Sophana was having trouble finding an OEM supplier for the
i9's (they are still relatively new). But if you want to put in a order for
the i9 before it is listed in the hardware catalog, contact Sophana (CCd)
and you can get the hook up.

While I'm here, we also have a contractor slated to add distributed
compilation to sccache [to replace icecream]. The contractor should start
in ~days. You can send questions, feature requests, etc through Ted for
now. We also had a meeting with IT and security last Friday about more
officially supporting distributed compilation in offices. We want people to
walk into any Mozilla office in the world and have distributed compilation
"just work." Hopefully we can deliver that in 2018.

On Tue, Jan 16, 2018 at 11:35 AM, Ralph Giles  wrote:

> On Tue, Jan 16, 2018 at 11:19 AM, Jean-Yves Avenard  >
> wrote:
>
> 12 minutes sounds rather long, it’s about what the macpro is currently
> > doing. I typically get compilation times similar to mac...
> >
>
> Yes, I'd like to see 7 minute build times again too! The E5-2643 has a
> higher clock speed than the Xeon W in the iMac Pro (3.4 vs 3.0 GHz) but a
> much lower peak frequency (3.7 vs 4.5 GHz) so maybe the iMac catches up
> during the single-process bottlenecks. Or it could be memory bandwidth.
>
>  -r
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requiring secure contexts for new features

[Ben Kelly]

On Tue, Jan 16, 2018 at 1:11 PM, Anne van Kesteren  wrote:

> * Modules might want to look into ways of enforcing this
> programmatically, to ease ongoing maintenance and guide everyone to do
> the right thing without having to ask/review/etc. E.g.,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
> for enforcement around our bindings.
>

FYI, Boris landed a change that requires the author to mark the test for an
interface as "insecureContext: true" if it should be permitted outside of a
secure context.  Obviously this should only be permitted going forward if
it meets one of our exception criteria.

Thanks.

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Tue, Jan 16, 2018 at 11:19 AM, Jean-Yves Avenard 
wrote:

12 minutes sounds rather long, it’s about what the macpro is currently
> doing. I typically get compilation times similar to mac...
>

Yes, I'd like to see 7 minute build times again too! The E5-2643 has a
higher clock speed than the Xeon W in the iMac Pro (3.4 vs 3.0 GHz) but a
much lower peak frequency (3.7 vs 4.5 GHz) so maybe the iMac catches up
during the single-process bottlenecks. Or it could be memory bandwidth.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Jean-Yves Avenard]

> On 16 Jan 2018, at 7:02 pm, Ralph Giles  wrote:
> 
> On my Lenovo P710 (2x2x6 core Xeon E5-2643 v4), Fedora 27 Linux
> 
> debug -Og build with gcc: 12:34
> debug -Og build with clang: 12:55
> opt build with clang: 11:51

I didn’t succeed in booting linux unfortunately. so I can’t compare…
12 minutes sounds rather long, it’s about what the macpro is currently doing. I 
typically get compilation times similar to mac...

> 
> Interestingly, I can almost no longer get any benefits when using icecream, 
> with 36 cores it saves 11s, with 52 cores it saves 50s only…
> 
> Are you staturating all 52 cores during the buidls? Most of the increase in 
> build time is new Rust code, and icecream doesn't distribute Rust. So in 
> addition to some long compile times for final crates limiting the minimum 
> build time, icecream doesn't help much in the run-up either. This is why I'm 
> excited about the distributed build feature we're adding to sccache.

icemon certainly shows all machines to be running (I ran it with -j36 and -j52)


> 
> I'd still expect some improvement from the C++ compilation though.
>  
> It’s a very sweet machine indeed
> 
> Glad you finally got one! :)
> 

probably will return it though, prefer to wait on the next mac pro.




smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Requiring secure contexts for new features

[Anne van Kesteren]

Yesterday Mozilla announced Firefox will be restricting new features
to secure contexts (i.e., HTTPS):

  https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

I'm glad to report that thus far this has been very well received.

I'm posting this here per suggestion from Ben Kelly and because:

* Not all module owners and peers might have seen the blog post and
this might impact them if their module currently, or in the future,
exposes features to web content.
* Modules might want to look into ways of enforcing this
programmatically, to ease ongoing maintenance and guide everyone to do
the right thing without having to ask/review/etc. E.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
for enforcement around our bindings.
* Mozillians might have questions not addressed in the post and this
seems like a good place to centralize those and address them.

Insofar as documenting this policy elsewhere goes I've updated
https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
manner. (The latter will probably also need to be generalized as
currently it suggests it's for APIs only.)

Hope that helps,


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Ralph Giles]

On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard 
wrote:

But I would be interested in knowing how long that same Lenovo P710 takes
> to compile *today*….
>

On my Lenovo P710 (2x2x6 core Xeon E5-2643 v4), Fedora 27 Linux

debug -Og build with gcc: 12:34
debug -Og build with clang: 12:55
opt build with clang: 11:51

Interestingly, I can almost no longer get any benefits when using icecream,
> with 36 cores it saves 11s, with 52 cores it saves 50s only…
>

Are you staturating all 52 cores during the buidls? Most of the increase in
build time is new Rust code, and icecream doesn't distribute Rust. So in
addition to some long compile times for final crates limiting the minimum
build time, icecream doesn't help much in the run-up either. This is why
I'm excited about the distributed build feature we're adding to sccache.

I'd still expect some improvement from the C++ compilation though.


> It’s a very sweet machine indeed
>

Glad you finally got one! :)

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Jean-Yves Avenard]

Sorry for resuming an old thread.

But I would be interested in knowing how long that same Lenovo P710 takes to 
compile *today*….
In the past 6 months, compilation times have certainly increased massively.

Anyhow, I’ve received yesterday the iMac Pro I ordered early December. It’s a 
10 cores Xeon-W (W-2150B) with 64GB RAM

Here are the timings I measured, in comparison with the Mac Pro 2013 I have 
(which until today was the fastest machines I had ever used)

macOS 10.13.2:
Mac Pro late 2013 : 13m25s
iMac Pro : 7m20s

Windows 10 fall creator
Mac Pro late 2013 : 24m32s (was 16 minutes less than a year ago!)
iMac Pro : 14m07s (16m10s with windows defender going)

Interestingly, I can almost no longer get any benefits when using icecream, 
with 36 cores it saves 11s, with 52 cores it saves 50s only…

It’s a very sweet machine indeed

Jean-Yves

> On 24 Mar 2017, at 11:32 am, Ted Mielczarek  wrote:
> 
> Just as a data point, I have one of those Lenovo P710 machines and I get
> 14-15 minute clobber builds on Windows.
> 
> -Ted



smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Avoid invoking Debug formatters in release-mode Rust

[Chris Peterson]

On 2018-01-12 9:07 PM, Bobby Holley wrote:

The most
common way this seems to happen is in panic!() messages, where it can be
tempting to include a stringified value to make the message more
informative.


Just a friendly reminder: panic messages that are parameterized to 
include debug data might expose PII in Firefox crash reports. Patches 
that add new parameterized panic messages should probably be reviewed by 
a data steward:


https://wiki.mozilla.org/Firefox/Data_Collection
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform