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 we should expose things at all that are unique to gecko/firefox to extensions? There are a whole bunch of things that get considered when new extension APIs are proposed including safety, maintainability, performance, and yes, cross-browser compatibility. Unfortunately, there isn't anything written that explains actual criteria in detail (its on our radar but somewhere behind a long list of engineering tasks on the short-term priority list). My individual opinion is that something being unique to gecko or firefox should not disqualify it from being exposed to extensions. The webcompat analogy doesn't really work here, the principle that the web should be open and interoperable demands rigor in what gets exposed to content. But a browser extension isn't a web page, it is part of the browser itself, and different browsers are inherently ... different. They have different features, different user interfaces, etc. The fact that browser extensions are built with web technology and that they modify or extend the very thing that displays web content obscures this distinction, but it does make a big difference. Anyway, containers is a good example of something that we've exposed to extensions that isn't likely to be supported in other browsers any time soon. Nevertheless, we need to design APIs in a way that doesn't compromise on the other areas mentioned above: maintainability, safety, performance. And, to the extent we can, we should design APIs that could be adopted by other browsers if they choose to. > Given our position, it's a bold move that says we're willing to take the > painful hit of pissing off addon authors and users because we truly believe > it is necessary to produce a top-quality product. There are certainly outraged addon authors out there but for what its worth, we're also already getting a good amount of positive feedback from both addon authors and users. That's my argument for why the default answer here should be "Heck yeah! If > we can provide something that other browsers don't, DO IT!" I could > describe it as a fairness/good faith argument instead: we just took away a > bunch of powerful tools from our users, claiming that it was for their own > long-term good, so it behooves us to give back whatever we can in a more > manageable form, in order to provide that promised good. > I think that's basically the attitude of most of the people working on webextensions. To be pedantic, the threshold is higher than "If we can". I mean, we *could* expose Components to webextensions but of course that would bring us right back to all the problems we're working on putting behind us. Again, documenting more formally specifically what it means for an extension API to be safe, maintainable, performant, etc. is something we know is needed. Hopefully when we come up for air after 57 we can work on this (and complementary things like webextensions experiments). -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 location bar > and/or tabbrowser. That was poorly worded -- these applications should create listeners for the various events that are generated during the install process. Whether you try to adapt the Firefox doorhangers somehow or keep some version of the current dialog (but apropos the original message in this thread, even that is likely to change) doesn't matter to me, but the existing code that displays a modal xul dialog from the guts of the addons manager isn't long for this world... This is straying off-topic for dev-platform, please follow up with me individually or on the dev-addons list if you have more questions. -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 them resolved ASAP. This work was accomplished without closing the trees, so big thank you to everyone who made this milestone possible. ~Justin Wood (Callek) On Wed, Jul 26, 2017 at 10:54 AM, Justin Wood wrote: > 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 today while stuff lands, and >> Nightlies will likely stay frozen to the latest buildbot-produced set until >> this evening or sometime tomorrow. >> >> Thank You again, >> ~Justin Wood (Callek) >> >> On Fri, Jul 21, 2017 at 2:59 PM, Justin Wood wrote: >> >>> Hello, >>> >>> tl;dr >>> >>> What: Windows opt & nightly builds switching to TaskCluster >>> >>> When: Wednesday, July 26th at 11:00ET >>> >>> Developer impact: Much rejoicing, Windows builds ~15 minutes faster, >>> Some Windows 10 testing switched to Tier1. >>> >>> Next Wednesday, July 26th, at 11:00ET we will be switching remaining >>> production windows builds from Buildbot to TaskCluster. Buildbot builds for >>> Windows will be disabled as this hits the trees. >>> >>> As part of this work, many TaskCluster Windows tests will also be >>> enabled as Tier1, including Windows 10 tests. Test suites requiring Windows >>> hardware, and tests that are not yet ready to migrate from Win8 to Win10 >>> will remain on Buildbot. For Win8 tests that already migrated to Win10, we >>> will disable the corresponding Win8 variants. >>> >>> If you have questions, please contact us in #releng or via email. >>> >>> Relevant bugs: >>> >>> Migrate Win64 nightly builds to TaskCluster >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1267427 >>> >>> Migrate Win32 nightly builds to TaskCluster >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1267428 >>> >>> FAQ: >>> >>> - Will builds running in TaskCluster be available more quickly? >>> >>> Builds in TaskCluster are approximately 15 minutes faster than in >>> buildbot. >>> >>> - Do the same tests pass/fail on a TC build as on a BB build? >>> >>> Yes, test results should be the same. Performance results should also be >>> the same >>> >>> - Will there be any impact to release schedules? >>> >>> No, We have performed additional testing to ensure a smooth Firefox 56 >>> Beta cycle, to be sure that we are ready with our release automation for >>> the changes this change brings with it, and we do not expect any delays to >>> the release pipeline with regard to this landing. >>> >>> Additionally we have scheduled this change to land on mozilla-central >>> now to minimize any potential impact it may have on efforts with Firefox 57 >>> and project Quantum. >>> >>> -How will Try be affected? >>> >>> Traditionally the Try Server has followed the configuration of >>> mozilla-central, however since the ability to test older branches on Try is >>> important we have devised the following short term plan. >>> >>> We will leave BB builds enabled on Try. >>> >>> When you push to Try from a Gecko 56+ tree after the changes land, you >>> will get TaskCluster and Buildbot builds, all testing will be triggered by >>> TaskCluster, and you can safely ignore the BB jobs. >>> >>> When you push to Try from Gecko 56 before this change or any older gecko >>> tree, you will get buildbot builds for your push, and all testing will be >>> triggered by buildbot. >>> >>> The test scheduling mentioned here is made possible by a configuration >>> item in mozharness we are toggling, so at the cost of some extra overhead >>> in Windows build load on Try we can support older branches. >>> >>> -How will Try be affected medium/long term? >>> >>> Medium term we hope to explore some options to make Buildbot builds be >>> off by default on Try, maybe requiring special Try syntax to enable them. >>> This is however not well defined yet, so we will followup with an e-mail to >>> these lists whenever we expect that to change. >>> >>> Long term, we will just turn off Try support of Windows Buildbot Builds, >>> and use strictly TaskCluster. >>> >>> -- >>> Thank You, >>> ~Justin Wood (Callek) >>> Mozilla Release Engineer >>> >>> >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 edge. Which means that people have a reason to choose us over the alternatives. And while we can and should look for other ways of doing that, via activity streams or privacy or Accounts or better tab handling, our historical edge has been extensibility and customizability. Firefox is sticky because people can make it do what they want, things that they come to depend on enough that they feel like they're missing out by switching browsers. (Even if people don't *actually* make use of it, knowing that the capability is there is powerful.) Indeed. Many of the changes the last few years have left a lot of users asking "if they are just copying Chrome, why shouldn't we switch to that?" I think "extensibility and customizability" is what kept many people from doing so, and now some of that is going away... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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, performance, etc. with a wide-open extension mechanism. Doing this at a time of weak market share is... courageous[2]. Given our position, it's a bold move that says we're willing to take the painful hit of pissing off addon authors and users because we truly believe it is necessary to produce a top-quality product. In short: better to have fewer users now with a high quality product that has the ability to grow, than to retain more users on a lower-quality product. But to make the sacrifice worthwhile, that means we have to *be* a high quality product. One with a competitive edge. Which means that people have a reason to choose us over the alternatives. And while we can and should look for other ways of doing that, via activity streams or privacy or Accounts or better tab handling, our historical edge has been extensibility and customizability. Firefox is sticky because people can make it do what they want, things that they come to depend on enough that they feel like they're missing out by switching browsers. (Even if people don't *actually* make use of it, knowing that the capability is there is powerful.) That's my argument for why the default answer here should be "Heck yeah! If we can provide something that other browsers don't, DO IT!" I could describe it as a fairness/good faith argument instead: we just took away a bunch of powerful tools from our users, claiming that it was for their own long-term good, so it behooves us to give back whatever we can in a more manageable form, in order to provide that promised good. The thing tempering this answer, of course, is that we don't want to paint ourselves into another corner[3]. The extension API is on its own standardization treadmill, and extension APIs that change or differ from what ends up getting standardized could be a problem. So I would hope that we've given this some serious thought and come up with a plan and policy for how to do it. I have ideas[4], but I certainly hope other people have given this a lot more thought already. 1. Calling the previous extension mechanism an API is giving it too much credit. "Stuff we didn't prevent from being used, that was useful for making addons"? 2. I would call it crazy and stupid move if I didn't happen to agree with it. Or if I was ok with calling myself crazy and stupid. And I'm not crazy. 3. Uh... I've never really thought about it before, but who paints their floors? I wouldn't think that'd wear well. I guess "Let's not Wet Swiffer ourselves into a corner!" doesn't have quite the same ring. 4. This scenario is easier than general web compatibility, because (1) we have an upgrade mechanism for addons, and (2) we're starting out so have the opportunity to set things up to make changes easier. For example, if you had to explicitly import specific extension points, it would be much easier to know what is being used and what might break; no need to bend over backwards to do feature detection. Also, some of the arguments against versioning JS or DOM don't apply here, so we might consider that in some form. We even have a signing mechanism, so we could control access on a per-API basis if it would help. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 (aka pharmaceutical lab) but it didn't work. Probably because pharmaceutical labs are closed worlds (because patents, economic interests, policies aka social structures). Browsers live in an open world were we expose what we do. This changes a lot of things. One of them is market forces. Vendor prefixes would be less terrible if all browsers had equal market shares (read here "unintentional power to modify the ecosystem" just to assume the best in everyone). As soon as some people are willing to adopt one of the browser "lab-style-features" in the open, because well it solves their issues and plays well with the ecosystem market shares, the vendor prefix strategy is falling apart for everyone else. It makes even things worse on a long term. Be open as much as possible. Draft specifications for things you think are interesting for the world. If something is really good for Gecko, it might be good for others. Don't compete on the uniqueness of your features, but on the excellency of your features. (just some thoughts from a 6+ years, and counting, webcompat frontline) -- Karl Dubost, mozilla 💡 Webcompat http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 >> browsers. > Until the day that said other browser gets forced into implementing > those prefixed names due to reasons such as mass adoption of the > prefixed names by developers. Here is a practical example from recent > history: > https://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/dom/webidl/HTMLInputElement.webidl#224 Yes, let's avoid repeating vendor-prefix history. It didn't end well last time. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 gets forced into implementing those prefixed names due to reasons such as mass adoption of the prefixed names by developers. Here is a practical example from recent history: https://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/dom/webidl/HTMLInputElement.webidl#224 Cheers, David On 26/07/17 05:55, Martin Thomson wrote: On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt wrote: On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: Should we moz-prefix moz-specific extensions? We have been trying not to do that for Web-exposed APIs but maybe the extensions case is different? I don't think that it is. If there is any risk at all that someone else might want to use it, then prefixing will only make our life harder long term. Good names are cheap enough that we don't need to wall ours off. See also https://tools.ietf.org/html/rfc6648 ___ 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: 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 here and see if we can fix it. It would be nice to make this work properly. > I’ve ended up keeping "classic" ccache for C and C++ code and adding > 'export RUSTC_WRAPPER=sccache' to my mach wrapper script in order to use > sccache for Rust code. (Having this line with or without 'export' in > .mozconfig did not appear to do anything. Can mozconfig set arbitrary > environment variables?) No, mozconfig variable setting is sort of restricted. Bare variable assignments (with or without export) are evaluated in the context of configure, but don't survive to the Makefile environment. If you write it as `mk_add_options export RUSTC_WRAPPER=sccache` that ought to work, since that will be set as an exported Makefile variable, meaning it will be set in the environment for commands executed by make. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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' to my mach wrapper script in order to use sccache for Rust code. (Having this line with or without 'export' in .mozconfig did not appear to do anything. Can mozconfig set arbitrary environment variables?) -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 following in my .mozconfig: ac_add_options --with-ccache mk_add_options 'export CCACHE_PREFIX=icecc' mk_add_options 'export CCACHE_CPP2=yes' Is there an equivalent / similar setup with sccache? Thanks, Botond [1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_Icecream ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 today while stuff lands, and Nightlies > will likely stay frozen to the latest buildbot-produced set until this > evening or sometime tomorrow. > > Thank You again, > ~Justin Wood (Callek) > > On Fri, Jul 21, 2017 at 2:59 PM, Justin Wood wrote: > >> Hello, >> >> tl;dr >> >> What: Windows opt & nightly builds switching to TaskCluster >> >> When: Wednesday, July 26th at 11:00ET >> >> Developer impact: Much rejoicing, Windows builds ~15 minutes faster, >> Some Windows 10 testing switched to Tier1. >> >> Next Wednesday, July 26th, at 11:00ET we will be switching remaining >> production windows builds from Buildbot to TaskCluster. Buildbot builds for >> Windows will be disabled as this hits the trees. >> >> As part of this work, many TaskCluster Windows tests will also be enabled >> as Tier1, including Windows 10 tests. Test suites requiring Windows >> hardware, and tests that are not yet ready to migrate from Win8 to Win10 >> will remain on Buildbot. For Win8 tests that already migrated to Win10, we >> will disable the corresponding Win8 variants. >> >> If you have questions, please contact us in #releng or via email. >> >> Relevant bugs: >> >> Migrate Win64 nightly builds to TaskCluster >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1267427 >> >> Migrate Win32 nightly builds to TaskCluster >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1267428 >> >> FAQ: >> >> - Will builds running in TaskCluster be available more quickly? >> >> Builds in TaskCluster are approximately 15 minutes faster than in >> buildbot. >> >> - Do the same tests pass/fail on a TC build as on a BB build? >> >> Yes, test results should be the same. Performance results should also be >> the same >> >> - Will there be any impact to release schedules? >> >> No, We have performed additional testing to ensure a smooth Firefox 56 >> Beta cycle, to be sure that we are ready with our release automation for >> the changes this change brings with it, and we do not expect any delays to >> the release pipeline with regard to this landing. >> >> Additionally we have scheduled this change to land on mozilla-central now >> to minimize any potential impact it may have on efforts with Firefox 57 and >> project Quantum. >> >> -How will Try be affected? >> >> Traditionally the Try Server has followed the configuration of >> mozilla-central, however since the ability to test older branches on Try is >> important we have devised the following short term plan. >> >> We will leave BB builds enabled on Try. >> >> When you push to Try from a Gecko 56+ tree after the changes land, you >> will get TaskCluster and Buildbot builds, all testing will be triggered by >> TaskCluster, and you can safely ignore the BB jobs. >> >> When you push to Try from Gecko 56 before this change or any older gecko >> tree, you will get buildbot builds for your push, and all testing will be >> triggered by buildbot. >> >> The test scheduling mentioned here is made possible by a configuration >> item in mozharness we are toggling, so at the cost of some extra overhead >> in Windows build load on Try we can support older branches. >> >> -How will Try be affected medium/long term? >> >> Medium term we hope to explore some options to make Buildbot builds be >> off by default on Try, maybe requiring special Try syntax to enable them. >> This is however not well defined yet, so we will followup with an e-mail to >> these lists whenever we expect that to change. >> >> Long term, we will just turn off Try support of Windows Buildbot Builds, >> and use strictly TaskCluster. >> >> -- >> Thank You, >> ~Justin Wood (Callek) >> Mozilla Release Engineer >> >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 full source paths included, so it's hard to get cache hits across machines when using different source directories. There's an sccache issue filed on this (and a patch sitting in the pull requests, actually), so it might be possible to make that work. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 ccache for local development. It's as > simple as adding this to your mozconfig (assuming sccache is in your > $PATH): > > ac_add_options --with-ccache=sccache > > The major benefit you gain over ccache is that sccache can cache Rust > compilation as well, and the amount of Rust code we're adding to Firefox > is growing quickly. (We're on track to enable building Stylo by default > soon, which will add quite a bit of Rust.) > > On my several-year-old Linux machine (Intel(R) Core(TM) i7-3770 CPU @ > 3.40GHz, 32GB, SSD), if I build; clobber; build with sccache enabled the > second (fully-cached) build completes in just over 4 minutes: > > 4:11.92 Overall system resources - Wall time: 252s; CPU: 69%; Read > bytes: 491520; Write bytes: 6626512896; Read time: 60; Write time: > 1674852 > > sccache still isn't completely straightforward to use on Windows[1] but > I aim to fix that this quarter so that using it there will be just as > simple as on other platforms. Windows support sounds very exciting! Will it support cache sharing? Kanru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 > ~/.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 mozconfig (assuming sccache is in your > $PATH): > > ac_add_options --with-ccache=sccache > > The major benefit you gain over ccache is that sccache can cache Rust > compilation as well, and the amount of Rust code we're adding to Firefox > is growing quickly. (We're on track to enable building Stylo by default > soon, which will add quite a bit of Rust.) > > On my several-year-old Linux machine (Intel(R) Core(TM) i7-3770 CPU @ > 3.40GHz, 32GB, SSD), if I build; clobber; build with sccache enabled the > second (fully-cached) build completes in just over 4 minutes: > > 4:11.92 Overall system resources - Wall time: 252s; CPU: 69%; Read > bytes: 491520; Write bytes: 6626512896; Read time: 60; Write time: > 1674852 > > sccache still isn't completely straightforward to use on Windows[1] but > I aim to fix that this quarter so that using it there will be just as > simple as on other platforms. > > -Ted > > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1318370 > ___ > 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: 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 evening or sometime tomorrow. Thank You again, ~Justin Wood (Callek) On Fri, Jul 21, 2017 at 2:59 PM, Justin Wood wrote: > Hello, > > tl;dr > > What: Windows opt & nightly builds switching to TaskCluster > > When: Wednesday, July 26th at 11:00ET > > Developer impact: Much rejoicing, Windows builds ~15 minutes faster, Some > Windows 10 testing switched to Tier1. > > Next Wednesday, July 26th, at 11:00ET we will be switching remaining > production windows builds from Buildbot to TaskCluster. Buildbot builds for > Windows will be disabled as this hits the trees. > > As part of this work, many TaskCluster Windows tests will also be enabled > as Tier1, including Windows 10 tests. Test suites requiring Windows > hardware, and tests that are not yet ready to migrate from Win8 to Win10 > will remain on Buildbot. For Win8 tests that already migrated to Win10, we > will disable the corresponding Win8 variants. > > If you have questions, please contact us in #releng or via email. > > Relevant bugs: > > Migrate Win64 nightly builds to TaskCluster > > https://bugzilla.mozilla.org/show_bug.cgi?id=1267427 > > Migrate Win32 nightly builds to TaskCluster > > https://bugzilla.mozilla.org/show_bug.cgi?id=1267428 > > FAQ: > > - Will builds running in TaskCluster be available more quickly? > > Builds in TaskCluster are approximately 15 minutes faster than in buildbot. > > - Do the same tests pass/fail on a TC build as on a BB build? > > Yes, test results should be the same. Performance results should also be > the same > > - Will there be any impact to release schedules? > > No, We have performed additional testing to ensure a smooth Firefox 56 > Beta cycle, to be sure that we are ready with our release automation for > the changes this change brings with it, and we do not expect any delays to > the release pipeline with regard to this landing. > > Additionally we have scheduled this change to land on mozilla-central now > to minimize any potential impact it may have on efforts with Firefox 57 and > project Quantum. > > -How will Try be affected? > > Traditionally the Try Server has followed the configuration of > mozilla-central, however since the ability to test older branches on Try is > important we have devised the following short term plan. > > We will leave BB builds enabled on Try. > > When you push to Try from a Gecko 56+ tree after the changes land, you > will get TaskCluster and Buildbot builds, all testing will be triggered by > TaskCluster, and you can safely ignore the BB jobs. > > When you push to Try from Gecko 56 before this change or any older gecko > tree, you will get buildbot builds for your push, and all testing will be > triggered by buildbot. > > The test scheduling mentioned here is made possible by a configuration > item in mozharness we are toggling, so at the cost of some extra overhead > in Windows build load on Try we can support older branches. > > -How will Try be affected medium/long term? > > Medium term we hope to explore some options to make Buildbot builds be off > by default on Try, maybe requiring special Try syntax to enable them. This > is however not well defined yet, so we will followup with an e-mail to > these lists whenever we expect that to change. > > Long term, we will just turn off Try support of Windows Buildbot Builds, > and use strictly TaskCluster. > > -- > Thank You, > ~Justin Wood (Callek) > Mozilla Release Engineer > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 mozconfig (assuming sccache is in your $PATH): ac_add_options --with-ccache=sccache The major benefit you gain over ccache is that sccache can cache Rust compilation as well, and the amount of Rust code we're adding to Firefox is growing quickly. (We're on track to enable building Stylo by default soon, which will add quite a bit of Rust.) On my several-year-old Linux machine (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 32GB, SSD), if I build; clobber; build with sccache enabled the second (fully-cached) build completes in just over 4 minutes: 4:11.92 Overall system resources - Wall time: 252s; CPU: 69%; Read bytes: 491520; Write bytes: 6626512896; Read time: 60; Write time: 1674852 sccache still isn't completely straightforward to use on Windows[1] but I aim to fix that this quarter so that using it there will be just as simple as on other platforms. -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1318370 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 process! ... > We're looking forward to also shipping this for Linux soon. This is now shipping in current Nightly. -- GCP ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 schreef Andrew Swan: On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch wrote: Since you're saying that we're still using the old interface, in fact Andrew said: "old add-on install confirmation dialog, that dialog includes a note about the certificate", would you be able to give us some exact DXR references which would save us a lot of searching. The dialog I mentioned is: https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallConfirm.xul The listbox in that dialog holds instances of: https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallItem.xml The label in those items with the class "xpinstallItemSigned" ends up holding either certificate details or some default message like "Author not verified" While we're on the topic, Thunderbird and Seamonkey should look at moving over to the doorhanger addon install flow that Firefox uses -- that xul dialog and everything that supports it are unused in Firefox and its days are numbered. -Andrew Looks like this indeed still used by both Thunderbird and SeaMonkey: http://i.imgur.com/Q7tQIsN.png (sorry for the Dutch screenshot). I've also verified with DOM Inspector, that this is indeed above mentioned dialog window. Onno ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 6:20 AM, Andrew Overholt wrote: >> On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: >>> Should we moz-prefix moz-specific extensions? >> >> We have been trying not to do that for Web-exposed APIs but maybe the >> extensions case is different? > > I don't think that it is. If there is any risk at all that someone > else might want to use it, then prefixing will only make our life > harder long term. Good names are cheap enough that we don't need to > wall ours off. > > See also https://tools.ietf.org/html/rfc6648 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
