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

On Wed, Jul 26, 2017 at 2:49 AM, Frank-Rainer Grahl wrote: > I need to look at the notifications for SeaMonkey anyway but how could > Thunderbird implement the standard doorhanger with no location bar? I think > the dialog should be retained for projects which do not have a

Re: Extensions and Gecko specific APIs

On Wed, Jul 26, 2017 at 4:27 PM, Steve Fink wrote: > This thread worries me greatly. Somebody tell me we have a plan and policy > around this already. Please? > We might, but I'm not sure what "this" you're concerned about. Whether API names should be prefixed? Or whether

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

I need to look at the notifications for SeaMonkey anyway but how could Thunderbird implement the standard doorhanger with no location bar? I think the dialog should be retained for projects which do not have a location bar and/or tabbrowser. FRG Onno Ekker wrote: Op 7/23/2017 om 2:12 AM

sccache as ccache

Yesterday I published sccache 0.2 to crates.io, so you can now `cargo install sccache` and get the latest version (it'll install to ~/.cargo/bin). If you build Firefox on Linux or OS X you can (and should) use sccache in place of ccache for local development. It's as simple as adding this to your

Re: Enabling filesystem read-restrictions for content process sandbox

On 06-07-17 16:07, Alex Gaynor wrote: > Hi dev-platform, > > On behalf of the Runtime Content Isolation (aka sandboxing) team, I'm > delighted > to announce that starting later this week, our macOS and Windows nightly > builds > will prohibit read access to most of the filesystem in the content

Re: Switching to TaskCluster Windows builds on Wednesday July 26th

Hello Everyone, Just a reminder that this work will be taking place in just under aproximately 2 hours. We are on track to complete it as outlined. Trees may be closed during parts of today while stuff lands, and Nightlies will likely stay frozen to the latest buildbot-produced set until this

Re: Extensions and Gecko specific APIs

Well, at least there is the matter of feature detection, for people who want to write code that will work in more than just Firefox. moz-prefixing makes it clear that the feature can be absent on some browsers. Cheers, David On 26/07/17 05:55, Martin Thomson wrote: > On Wed, Jul 26, 2017 at

Re: sccache as ccache

On Wed, Jul 26, 2017, at 09:05 PM, Ted Mielczarek wrote: > Yesterday I published sccache 0.2 to crates.io, so you can now `cargo > install sccache` and get the latest version (it'll install to > ~/.cargo/bin). If you build Firefox on Linux or OS X you can (and > should) use sccache in place of

Re: Switching to TaskCluster Windows builds on Wednesday July 26th

This work has now begun. On Wed, Jul 26, 2017 at 9:13 AM, Justin Wood wrote: > Hello Everyone, > > Just a reminder that this work will be taking place in just under > aproximately 2 hours. We are on track to complete it as outlined. > > Trees may be closed during parts of

Re: sccache as ccache

On Wed, Jul 26, 2017, at 10:46 AM, Kan-Ru Chen wrote: > Windows support sounds very exciting! Will it support cache sharing? Currently sccache supports a few different cache storage backends: * local disk * Amazon S3 * Google Cloud Storage * Redis However, the cache keys currently wind up with

Re: sccache as ccache

On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek wrote: > If you build Firefox on Linux or OS X you can (and > should) use sccache in place of ccache for local development. Can sccache be used in conjunction with icecc [1]? I currently use the two together by having the

Re: sccache as ccache

If you're on macOS, you can also get sccache with `brew install sccache`. Alex On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek wrote: > Yesterday I published sccache 0.2 to crates.io, so you can now `cargo > install sccache` and get the latest version (it'll install to >

Re: sccache as ccache

On 26/07/2017 15:05, Ted Mielczarek wrote: ac_add_options --with-ccache=sccache When used together with icecc, this appears to force all jobs to run locally which makes icecc pointless. I’ve ended up keeping "classic" ccache for C and C++ code and adding 'export RUSTC_WRAPPER=sccache'

Re: sccache as ccache

On Wed, Jul 26, 2017, at 12:57 PM, Simon Sapin wrote: > On 26/07/2017 15:05, Ted Mielczarek wrote: > >ac_add_options --with-ccache=sccache > > When used together with icecc, this appears to force all jobs to run > locally which makes icecc pointless. We should figure out what's going on

Re: Extensions and Gecko specific APIs

On 7/26/17 3:06 PM, Ehsan Akhgari wrote: > On 07/26/2017 04:58 AM, David Teller wrote: >> Well, at least there is the matter of feature detection, for people who >> want to write code that will work in more than just Firefox. >> moz-prefixing makes it clear that the feature can be absent on some

Re: Extensions and Gecko specific APIs

On 07/26/2017 04:58 AM, David Teller wrote: Well, at least there is the matter of feature detection, for people who want to write code that will work in more than just Firefox. moz-prefixing makes it clear that the feature can be absent on some browsers. Until the day that said other browser

Re: Extensions and Gecko specific APIs

On 7/26/2017 4:27 PM, Steve Fink wrote: it's a bold move that says we're willing to take the painful hit of pissing off addon authors and users That has certainly happened... But to make the sacrifice worthwhile, that means we have to *be* a high quality product. One with a competitive

Re: Extensions and Gecko specific APIs

David, others, Le 26 juil. 2017 à 17:58, David Teller a écrit : > moz-prefixing makes it clear that the feature can be absent on some > browsers. vendor prefixes were of a good intent, an idea of a safe space to explore a technology without breaking stuff in the real world

Re: Extensions and Gecko specific APIs

This thread worries me greatly. Somebody tell me we have a plan and policy around this already. Please? We're taking the regrettable but necessary step of killing off legacy style extension "APIs"[1]. Necessary because e10s and the basic impossibility of maintaining security, stability,

Re: [tools-tc] Switching to TaskCluster Windows builds on Wednesday July 26th

This was a huge project full of detailed requirements and challenges, and an important step in the taskcluster migration. Congratulations to everyone who worked so hard to make it happen! Dustin ___ dev-platform mailing list

Re: Switching to TaskCluster Windows builds on Wednesday July 26th

As of now we are declaring this work a success! We have unfrozen Nightly updates for 10% of our userbase right now. We plan to update 100% of our users tomorrow after the next set of Nightlies are produced. There are a few minor issues we are following up on at this time, but expect to have