Node 10 now required on mozilla-central, please run `mach bootstrap`
Node 10 support has now merged to mozilla-central, see below for more details: On Tue, 11 Feb 2020 at 12:49, Dan Mosedale wrote: > After the patch from [1] merges to mozilla-central and you’ve > updated your copy of m-c, in order for your builds to continue to > work: > > for downstream OS distributions: > * Ensure that a copy of NodeJS 10.* (or newer?) is the first copy in > the PATH when the build is done. > > for individual developers: > * Run `mach bootstrap` to update the copy of Node used by the build system. > > If you have any questions or issues, feel free to ask here, ping me > directly, or ask in #NodeJS on Slack. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1547823#c28 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upgrading to Node 10 early Nightly 75 (week of February 10th)
As Ed Lee posted last week [1], we’re about to start requiring NodeJS version 10 for our builds for Firefox 75 and later [2]. In the next small number of days, I plan to land this change via Lando. After the patch from [2] merges to mozilla-central and you’ve updated your copy of m-c, in order for your builds to continue to work: for downstream OS distributions: * Ensure that a copy of NodeJS 10.* (or newer?) is the first copy in the PATH when the build is done. for individual developers: * Run `mach bootstrap` to update the copy of Node used by the build system. If you have any questions or issues, feel free to ask here, ping me directly, or ask in #NodeJS on Slack. I’ll post again after the changes have landed, so that folks have this info at hand when they need it. [1] https://groups.google.com/d/msg/mozilla.dev.platform/YMzkiE29BK0/hcEgWMzOAwAJ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1547823#c28 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
please run mach bootstrap; NodeJS/NPM security fixes landed
* Upgrades for NodeJS from 8.11.3 to 8.17.0 and for NPM from 5.6.0 to 6.13.4 have merged to mozilla-central. * Everyone is encouraged to run `mach bootstrap` to upgrade the toolchain on their machine. * The main security fix that we’re concerned with is in npm, so I’ve also set 6.13.4 as the minimum acceptable npm version that mach commands will allow. This means that running mach `mach eslint —setup` will abort until you upgrade your npm (i.e. you run `mach bootstrap`, in most cases). https://bugzilla.mozilla.org/show_bug.cgi?id=1604295 has more details. Dan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
NodeJS vendoring policies; feedback requested
Now that we have NodeJS in the tree, we want to unlock the rich set of tooling in the NodeJS/npm ecosystem so that we can start depending on things available there in a coherent, managed, more secure way. We've drafted policy docs to govern use and management of those packages, and we'd love your feedback: https://github.com/dmose/mc-nodejs-docs/ If possible, file a github issue or PR there. However, if that's too much friction, feel free to send an email to nodejs-pe...@mozilla.org, and one of us can break it out. Once these docs are done enough, we'll get signoff from required stakeholders (that list of people is still being sorted out) and then land them into mozilla-central. At that point, they will be regularly published to firefox-source-docs.mozilla.org as part of `mach doc`, and maintained there. For those interested in reviewing the plan itself, that's available at https://docs.google.com/document/d/1YlwKZgxgWO4kT7YEZLSb2SlpPMa0eos2v8_oJ76brrc/ Thanks, Dan (on behalf of the many folks who have worked on & helped with these documents) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using MozPhab without Arcanist
Also, if you did the double self-update to move over to pip while running under pyenv, moz-phab may suddenly disappear from your path until you restart your shell. Dan Am Do., 24. Okt. 2019 um 03:55 Uhr schrieb Axel Hecht : > > Am 24.10.19 um 12:13 schrieb Henrik Skupin: > > glob wrote on 23.10.19 17:56: > > > >> It's available now - make sure you're running the latest version by > >> running `moz-phab self-update`. > > > > That's what I did yesterday, but as it looks like the self-update > > actually didn't update my version to the latest MozPhab-0.1.55. I will > > check soon with this version. Thanks! > > > > Henrik > > > > You need to run self-update twice to move over to the pip version. > > Also, make sure to not run it while in a virtualenv like I did. > Otherwise you end up uninstalling and installing it from scratch ;-) > > Axel > ___ > 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: The sec-approval process makes users safer
Seems like it ought to be straightforward to do something to cause in-testsuite? flags to send mail occasionally, or show up on some dashboard, or... Dan Am Di., 10. Sept. 2019 um 09:11 Uhr schrieb Andrew McCreight : > > On Tue, Sep 10, 2019 at 4:55 PM Dave Townsend wrote: > > > On Mon, Sep 9, 2019 at 6:01 PM Jeff Walden wrote: > > > > > Those of you longer in the tooth may remember Firefox was successfully > > > exploited in Pwn2own 2012...and we didn't have to lift a finger to fix > > it. > > > We already had -- in the Firefox release shipping days later. 🤦 > > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=735104 (pwn2own bug) > > > https://bugzilla.mozilla.org/show_bug.cgi?id=720511 (cover bug, > > > discussion only of a spec-compliance issue) > > > https://bugzilla.mozilla.org/show_bug.cgi?id=720079 (sec bug noting the > > > sec issue) > > > > > > We later discussed whether the exploit had been "achieved" by reading our > > > public commits. https://bugzilla.mozilla.org/show_bug.cgi?id=735104#c2 > > > The fruit of this discussion was our security approval process, where > > > security patches land only after approval, in relative lockstep close to > > > release, with incriminating tests/comments removed. This is also where > > > sec-approval comment hoop-jumping began. > > > > > > How often do we go back and land those tests and comments after the fix has > > been in the release builds for a suitable amount of time? > > > > In theory, you should set the in-testsuite? flag when you land without the > test, and then when the bug is opened, land the test, but in practice I > don't think anybody makes sure that happens. I feel like I've seen one or > two cases over the years where we fixed some sec issue, no test landed, > then much later we regressed it. > > ___ > > 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: Improving our usage of Bugzilla
I've looked at the UX spec and Sylvestre's announcement, and I have some relevant experience here working on teams which have used the "enhancement" value of the "severity" field with the intent of using that information to monitor our rate of defect introduction. That workflow has turned out to have a footgun that has polluted our usage, which appears to me to be replicated here, and which I think has a simple fix. I'd be curious to hear thoughts: In particular, the severity field defaults to "normal", which we'd like to use to mean a "normally severe defect". Unfortunately, because the default is set to "normal" and because Bugzilla has such a large number of fields, what it actually means in practice is either "normally severe defect" or "bug-filer was in a hurry or not paying attention", with no easy way to tell the difference. And that happens a non-trivial amount of the time. Some fields in bugzilla have a "---" value (including severity, but it's not the default). This can be used to mean "not-entered" or "untriaged", completely eliminating the "hard-to-detect-bad-data issue". I'm concerned that the Type field as currently proposed (i.e. no --- field as default) has effectively the same footgun, which will make the data we gather with it less useful. Thoughts? Dan Am Di., 12. März 2019 um 12:10 Uhr schrieb Felipe G : > > Does performance work count as "enhancement" or "task"? > On one hand, it's not strictly refactoring.. On the other hand, it is not > development of a new feature, per the proposed description of enhancement. > > On Tue, Mar 12, 2019 at 3:20 PM Onno Ekker wrote: > > > On 12/03/2019 18:59, Sylvestre Ledru wrote: > > > Le 12/03/2019 à 17:48, Andrew McCreight a écrit : > > >> > > >> Secondly, to bikeshed a little, could there be some name besides > > >> "task" for > > >> that third category? Like I said above, everything we work as > > >> developers is > > >> a developer task. "Refactor" seems like a clearer name, though maybe > > >> it is > > >> a little limiting. "Side grade"? :) > > > > > > This is more than just refactoring. It is more "as an engineer, here is > > > what I have to do". > > > > Maybe call it "Engineering"? "Maintenance"? > > ___ > > 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: PSA: Min clang / libclang requirement was updated not long ago...
Am Mi., 27. Feb. 2019 um 06:28 Uhr schrieb Nathan Froyd : > > > If people have problems with bootstrap (it doesn't do enough, it > > > assumes too much about your system, etc. etc.), please file bugs on > > > what's wrong. We need to start depending more on bootstrap for > > > everything, to the point of "you can't depend on X unless it gets > > > installed via bootstrap", and we can't get to that world if we don't > > > know what rough edges people find in bootstrap. > > > > Do you have a suggestion on how to do that in practice? Rolling back > > from a broken development environment is easily a couple of hours of > > work, in the case of homebrew breaking all my virtualenvs, for example. > > It's not clear to me what bootstrap does that breaks things. Do you > want the ability to skip installing everything via homebrew? Note that it is already possible to skip all changes that touch the system package manager by doing `mach bootstrap --no-system-changes`. This won't install everything that is required to build, but it should at least install the stuff that is available as pre-built toolchains from CI (including clang, node, cbindgen, etc). I suspect (but don't know), that most (all?) recent changes to mach bootstrap fall under this grouping. Perhaps making it possible to force `mach bootstrap --no-system-changes` after a key change would be reasonable and solve a sufficient subset of the problem for now? It would still have the re-download issue that dmajor pointed out, although I suppose that bug could be made to block the option to force. Dan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
devs: please install NodeJS; it will be required by default on Thurs, Aug 17th
This Thursday, August 17th, we’ll be turning on —enable-nodejs in the mozilla-central build system by default. This means that, for developers who haven't yet run `mach bootstrap --no-system-changes`, the build may stop working until that happens. For those on Mac, Windows, and many recent versions of Linux, executing “mach bootstrap --no-system-changes” command should install the right Node version in your ~/.mozbuild directory and Just Work and should generally take 5 minutes or less. For more details, including what developers on other platforms need to do, see the [announcement posting](http://bit.ly/2BbyD1E). 1. Make sure you’ve updated your copy of mozilla-central since Monday, August 13th, 3:01 pm Pacific (Tues, Aug 14 00:00:01 CET). 2. From the command line, in your mozilla-central tree: ./mach bootstrap --no-system-changes && ./mach configure && ( ./mach configure | grep -i "checking for node") 3. The last couple of output lines should look something like this: Mac/Linux: 0:01.65 checking for nodejs... /Users/dmose/.mozbuild/node/bin/node 0:01.66 checking for node.js version… 8.11.3 Windows: 0:12.93 checking for nodejs... 'c:/Users/DANMOS~1/MOZBUI~1/node/node.exe' 0:12.99 checking for node.js version… 8.11.3 If something fails, or if the version is something other than 8.11.3, or if the path doesn’t contain either "MOZBUI" or ".mozbuild", please [file a bug](https://mzl.la/2OiVPNd). For extra bonus points, we’d love it if you would update the [compatibility spreadsheet](http://bit.ly/2ONtXC5), so that we can have a good sense of whether we’re ready to throw the switch on Thursday. Once --enable-nodejs is on by default, if you do have any problems, it will be very easy to delay dealing with this until early in the Firefox 64 cycle by simply adding `ac_add_options --disable-nodejs` to your .mozconfig file. If you have any questions/problems/concerns/issues, here are some first-line options: * For technical/process questions, feel free to respond to the mailing list where you saw this question, email me directly, or ask in #go-node in slack. * For bigger issues (eg “I don’t think this should land yet”, “there’s a big problem that’s likely to affect one or more groups of people”), feel free to reach out to one of: Dan Mosedale (me) <https://mozillians.org/en-US/u/dmose/>, Greg Szorc (build module owner - https://mozillians.org/en-US/u/gps/), or Kim Moir (engineering manager, build and vcs - https://mozillians.org/en-US/u/kmoir/). Thanks, Dan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Upcoming Firefox NodeJS 8 build requirement (soft for Fx 63, hard for Fx 64)
ckages from the npm or yarn registries are landing as part of this patch. - In the immediate future, individual packages will be vendored in on a case-by-case basis. - Immediately after NodeJS lands, and before we start landing packages into the top-level node_modules, I’ll be drafting some straw-man policies for packages and their dependencies (i.e., specific details on what sorts of packages will be allowed, how we’ll handle security, licenses, etc). I’ll be posting to the usual places (mozilla.dev.builds, mozilla.dev.platform, firefox-dev) requesting comment and further discussion. What’s next for Node in the tree? - The first customer for this code is expected to be DevTools, who will use a standalone version of Babel to transpile JSX to JS files as part of the build (bug 1461714 <https://bugzilla.mozilla.org/show_bug.cgi?id=1461714>), so that checking in JS build artifacts is no longer necessary. This will be a first step in making risk-analysis / bug-finding / uplifting more efficient for release engineers, sheriffs, and others. - Drafting, circulating, and iterating on the node_modules proposal described above. - Landing an initial prototype of a single node_module with dependencies (possibly PostCSS) Where can I read a more detailed analysis as to why we’re doing this? - The detailed rationale, along with important tradeoffs and risks, are described in Nick Alexander’s Intent-to-require document <https://docs.google.com/document/d/1tOA2aeyjT93OoMv5tUMhAPOkf4rF_IJIHCAoJlwmDHI/edit?usp=sharing>, which was posted for comment to dev-platform <https://groups.google.com/forum/#!topic/mozilla.dev.platform/7sPFmewLoUg> and dev-builds <https://groups.google.com/d/msg/mozilla.dev.builds/kuo6WycEcFk/jrdYydhHAQAJ> in February. Note that a few parts of the document are out of date, and I’ve attempted to annotate those parts as comments in the document. There is still a problem/concern/issue that I think needs to be addressed before the landing happens. What should I do? - For technical/process questions, feel free to respond to the mailing list where you saw this question, email me directly, or ask in #go-node in slack. - For bigger issues (eg “I don’t think this should land yet”, “there’s a big problem that’s likely to affect one or more groups of people”), feel free to reach out to one of: Dan Mosedale (me) < https://mozillians.org/en-US/u/dmose/>, Greg Szorc (build module owner - https://mozillians.org/en-US/u/gps/), or Kim Moir (engineering manager, build and vcs - https://mozillians.org/en-US/u/kmoir/). Thanks muchly to a bunch of folks who have helped make this happen; most especially Nick Alexander and Greg Szorc, but also (in alphabetical order) Alexander Poirot, Chris Karlof, Jason Laster, Kate Hudson, Kim Moir, Mike Shal, and Tim Spurway. Apologies to anyone I’ve inadvertently forgotten! Dan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We need better canaries for JS code
Dave, how would you feel about deciding on one of those and allowing modules to opt-in to using them, perhaps just as an experiment. Presumably most existing modules wouldn't, but new ones being written might. Dan 2017-10-18 9:06 GMT-07:00 Dave Townsend : > On Wed, Oct 18, 2017 at 4:51 AM Mark Banner wrote: > >> I remember that we had bugs of this kind lurking for years in our >> codebase, in code that was triggered daily and that everybody believed >> to be tested. >> >> I'd like to think that there is a better way to handle these bugs, >> without waiting for them to explode in our user's face. Opening this >> thread to see if we can find a way to somehow "solve" these bugs, either >> by making them impossible, or by making them much easier to solve. >> >> ESLint has caught some bugs - mainly undefined and unused related issues, >> and is spread through most of the production javascript code. Unfortunately >> it isn't able to catch this class of error. For that, we'd need something >> like Flow. Last time I looked at it, it didn't feel like a good fit for us, >> although I didn't go too deep, and I think there may have been other people >> that were looking at it. >> > > As a datapoint, I've looked at both Flow and TypeScript. Both are good > tools that work well if you're writing code from scratch with them but for > existing code they flag many many pre-existing problems, the vast majority > of which aren't really problems just cases where the tools can't infer what > is going on without adding type info to the script. I came to the > conclusion that it would be too much work to use either in our main > codebase. > > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We need better canaries for JS code
Could we do this on a per-module opt-in basis to allow for gradual migration? That is to say, assuming there's enough information in the stack to tell where it was thrown from (I'm guessing that's the case most of the time), by default, ignore these errors unless they're from code in an opted-in module? Dan 2017-10-18 11:51 GMT-07:00 Ryan VanderMeulen : > Note that we also have bug 920191 on file for making JS exceptions fatal > in the harness. One of the big blockers to that has always been cleaning up > the existing set of problems, but maybe it would be helpful for some of > these issues if/when we could drive that into happening. > > -Ryan > > > On Wed, Oct 18, 2017 at 12:20 PM, J. Ryan Stinnett > wrote: > >> This may not be what you want here, but just so you are aware of the >> option... >> >> You can use `Services.console.registerListener`[1] in a test harness, >> etc. to hear messages logged to the console. The harness could count >> messages of a certain type (like script errors) and fail the test if >> there's an unexpected count (similar to assertion handling in some >> harnesses). >> >> Some test harnesses already register console listeners, but many of them >> just echo the messages to the test log without examining them further. >> >> For JS errors logged to the console, you can QI them to nsIScriptError >> and examine more details like line, column, stack, etc. >> >> Anyway, might not cover all the cases envisioned here, but it's one tool >> available to us. >> >> [1]: http://searchfox.org/mozilla-central/search?q=console.regist >> erListener&case=true®exp=false&path= >> >> - Ryan >> >> On Wed, Oct 18, 2017 at 6:51 AM, Mark Banner wrote: >> >>> Looping in firefox-dev as well, as I thin this is an important >>> discussion. >>> >>> On 18/10/2017 09:28, David Teller wrote: >>> >>> Hi everyone, >>> >>> Yesterday, Nightly was broken on Linux and MacOS because of a typo in >>> JS code [1]. If I understand correctly, this triggered the usual >>> "undefined is not a function", which was >>> >>> 1/ uncaught during testing, as these things often are; >>> >>> Part of the reason it was uncaught, is that there's no automated test >>> coverage for that bit of code. It is a migration from one version to the >>> other, but unless there is an explicit test (and I don't see one) that line >>> won't be hit. >>> >>> This seems to be a common theme with various migration routes in the >>> code base, when I've asked about ensuring more automated testing there >>> before I feel like I've got shrugs. >>> >>> Admittedly, a lot of it is simple code, and should be correct, but as >>> we've seen, mistakes can be made. Should we now be changing our policy? >>> >>> At a minimum, I wonder if we could write some sort of simple test for >>> CustomizableUI that would go through most routes (with minimal updates for >>> each change). >>> >>> 2/ basically impossible to diagnose in the wild, because there was no >>> error message of any kind. >>> >>> I did an experiment, and the only way I got an error out was to have >>> "javascript.options.strict" on and "browser.dom.window.dump.enabled". >>> Unfortunately the breakage was such that the browser console couldn't be >>> opened, so you'd just having strict on wasn't enough. >>> >>> I remember that we had bugs of this kind lurking for years in our >>> codebase, in code that was triggered daily and that everybody believed >>> to be tested. >>> >>> I'd like to think that there is a better way to handle these bugs, >>> without waiting for them to explode in our user's face. Opening this >>> thread to see if we can find a way to somehow "solve" these bugs, either >>> by making them impossible, or by making them much easier to solve. >>> >>> ESLint has caught some bugs - mainly undefined and unused related >>> issues, and is spread through most of the production javascript code. >>> Unfortunately it isn't able to catch this class of error. For that, we'd >>> need something like Flow. Last time I looked at it, it didn't feel like a >>> good fit for us, although I didn't go too deep, and I think there may have >>> been other people that were looking at it. >>> >>> I have one proposal. Could we change the behavior of the JS VM as follows? >>> >>> - The changes affect only Nightly. >>> - The changes affect only mozilla chrome code (including system add-ons >>> but not user add-ons or test code). >>> - Any programmer error (e.g. SyntaxError) causes a crash a crash that >>> displays (and attaches to the CrashReporter) both the JS stack in and >>> the native stack. >>> - Any SyntaxError is a programmer error. >>> - Any TypeError is a programmer error. >>> >>> I expect that this will find a number of lurking errorsy, so we may want >>> to migrate code progressively, using a directive, say "use strict >>> moz-platform" and static analysis to help encourage using this directive. >>> >>> It would definitely be interesting to fail tests on some of the strict >>> failures. I was surpri
Re: Reminder on Try usage and infrastructure resources
I wonder if this isn't (in large part) a design problem disguised as a
behavior problem. The existing try syntax (even with try chooser) is so
finicky and filled with abbreviations that even after years of working with
it, I still regularly have to look up stuff and sometimes when I've been in
a hurry, I've done something more general than I really needed because it
was just too painful to figure out the exact thing.
I'd be pretty surprised if developers newer to the mozilla infrastructure
than I didn't end up doing this sort of thing substantially more frequently.
https://ahal.ca/blog/2017/mach-try-fuzzy/ seems like a fine step in the
right direction, and maybe that'll be enough.
But I do wonder if the path to saving substantial time and money in the
long run is to invest some real user-research / UX / design time into
designing a try configurator where it requires effort to do the
unnecessarily expensive thing, as opposed to the current situation, where
it requires effort to avoid the expensive thing.
Dan
2017-09-15 9:46 GMT-07:00 Geoffrey Brown :
> Masayuki, your try push had trouble because you requested
> "mochitest-2" instead of "mochitest-e10s-2". Non-e10s mochitests only
> run on Android and Windows now. You probably wanted something like:
>
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=
> d68382f17d63f0674c62acc7242a9e406793895f
>
>
> This is a good example of how a small deviation from "correct" try
> syntax can have unexpected and frustrating consequences.
>
> - Geoff
>
> On Thu, Sep 14, 2017 at 7:15 PM, Masayuki Nakano
> wrote:
> > I tried to say different point. See the treehearder log, mochitests
> didn't
> > run except on Win7 Debug, Android 4.3 API16+ Opt/Debug. So, try syntax
> > parser or something is really broken. I often meet this kind of bug.
> >
> >
> > On 9/15/2017 10:07 AM, Kris Maglione wrote:
> >>
> >> Your best bet is probably to use `mach try` with a specific set of test
> >> directories. It will generate a set of --try-test-paths flags to
> restrict
> >> tests to those paths, and only run the first chunk of any group. Without
> >> that, groups shift around too much to be reliable.
> >>
> >> On Fri, Sep 15, 2017 at 10:03:00AM +0900, Masayuki Nakano wrote:
> >>>
> >>> Even when I got the chunk numbers, specifying chunk numbers of
> mochitests
> >>> wouldn't work, see this log:
> >>>
> >>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=
> c09c7046ed0664e89f7224e1de5219c39c94c948
> >>> After that, I needed to rerun mochitests with |-u mochitests|. IIRC, I
> >>> tried to kick the specific chunks with "Add new jobs", but didn't work.
> >>> And also, when I try to investigate random oranges which are not
> >>> reproducible on my environments, I want an option like
> |--run-until-failure|
> >>> and |--repeat REPEAT| in the try syntax. Because of no such options, I
> need
> >>> to trigger a lot of jobs manually and that may/might cause too many
> oranges.
> >>>
> >>> On 9/15/2017 1:21 AM, Kyle Lahnakoski wrote:
>
>
> You can try ActiveData, which stores all test results from the past
> few
> weeks. Here is an example query that shows the chunk number for each
> run/build combo in the past day. ActiveData is sometimes more than a
> day behind
>
> https://activedata.allizom.org/tools/query.html#query_id=4HHuBgDu
>
> {
> "from":"unittest",
> "select":[
> {"aggregate":"count"},
> {"value":"action.start_time","aggregate":"max"}
> ],
> "groupby":[
> "run.suite",
> "run.chunk",
> "result.test",
> "build.platform",
> "build.type",
> "run.type"
> ],
> "where":{"and":[
> {"eq":{"build.branch":"mozilla-inbound"}},
> {"prefix":{"run.suite":"moch"}},
> {"gt":{"action.start_time":{"date":"today-day"}}},
> {"regex":{"result.test":".*browser_623779.js.*"}}
> ]},
> "limit":1000
> }
>
>
>
> On 2017-09-14 11:49, Michael de Boer wrote:
> >>
> >> On 14 Sep 2017, at 17:48, Marco Bonardo
> wrote:
> >>
> >> When I need to retrigger a mochitest-browser test multiple times (to
> >> investigate an intermittent), often I end up running all the
> >> mochitest-browser tests, looking at every log until I find the chunk
> >> where the test is, and retrigger just that chunk. The chunk number
> >> changes based on the platform and debug/opt, so it's painful.
> >> Is there a way to trigger only the chunk that will contain a given
> >> test, so I can save running all of the other chunks?
> >
> > This! This! This! I’d love to be able to do this - would making
> testing
> > possible test failure fixes sooo much easier.
> >
> > Cheers,
> >
> > Mike.
> >
>
> >>>
> >>>
> >>> --
> >>> Masayuki Nakano
> >>> Software En
Re: Shipping Headless Firefox on Linux
2017-06-16 6:22 GMT-07:00 Ehsan Akhgari : > On 06/15/2017 04:37 PM, Nathan Froyd wrote: > >> Would it be feasible to use headless mode for mochitests (or reftests, >> etc. etc.)? >> > Running the tests that we rely on for correctness on an environment that > looks this different than the environment that our users run sounds like a > bad thing to do. What would be the advantage of doing so? Two advantages would be: * it would likely be much faster, allowing folks to get a substantially tighter feedback loop of developing and running a set of tests. My expectation, based on previous experience in the web-development world, is that people would run tests more often during the development cycle, which would catch other errors more quickly during development, making development more efficient. * it would allow you to run (some part of a) test suite without having to use a VM, a separate machine, or some other hack to avoid messing up all the tests that are focus-dependent. This would also likely lead to more frequent local test runs. The concerns about differing environment do sound reasonable. One conceivable way forward might be to start by adding add headless testing infrastructure to the tree so that developers could use them locally as "smoke tests", and then run the real tests locally or by try before landing. At the same time, they could added as Tier > 1 tests so that we could collect data to see what the level of failure differences between those tests and normal mochitests are to figure out next steps. Dan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Visual Studio Code recommended extensions
It sounds like you find it better than Atom. If that's true, any chance you could elaborate on what you find particularly nicer and/or what's missing? Thanks, Dan 2017-02-24 5:49 GMT-08:00 James Cheng : > Hi, > Is it possible to configure VSCode to make "watch window" show "value" > with *"type" *information especially for strong typed language C++? > > > Cheers, > James > > > 2017-02-24 0:48 GMT+08:00 Marco Bonardo : > >> Hi, >> I recently started testing VS Code as a replacement for Sublime Text or >> Atom, and so far the experience has been better than I was expecting. I >> suspect others of you are doing the same. >> >> In bug 1341585, I'm adding .vscode/settings.json to the ignore lists, so >> that everyone can create his own workspace settings file. >> >> Additionally, I'd like to provide an extensions.json that contains a list >> of extensions "recommended" to newcomers. The purpose is to help new >> contributors setting up their editor if they'd ever decide to use VS Code. >> These extensions are suggested the first time the worskspace (src root >> dir) >> is opened, and can be reached at any time through the Show Recommended >> Extensions for this Workspace menu. they are only suggested, not installed >> by default. >> >> I'd like you to help me figuring out this list of extensions. Please >> provide feedback about the ones I picked, and suggest others that you are >> using for your everyday work. >> >> My current list: >> // Trim only touched lines. >> "NathanRidley.autotrim", >> >> // Hilight trailing whitespaces. >> "ybaumes.highlight-trailing-white-spaces", >> >> // JS Babel ES6/ES7 syntax hilight. >> "dzannotti.vscode-babel-coloring", >> "dzannotti.theme-spacemacs", >> >> // ESLint support. >> "dbaeumer.vscode-eslint", >> >> // C/C++ language support. >> "ms-vscode.cpptools", >> >> // Rust language support. >> "saviorisdead.RustyCode" >> >> Thank you >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What if you could reinvent Firefox theming?
I've had good luck with https://addons.mozilla.org/en-US/firefox/addon/theme-font-size-changer/ on Mac. It may be a good place to play with some of the user-experiences available if we want to provide something in core Firefox... Dan 2016-09-09 17:23 GMT-07:00 Myk Melez : > Justin Dolske > 2016 September 8 at 15:41 > > "Make things bigger" is somewhat curious... On Windows this is typically > done by adjusting the display scaling factor in the OS settings. I wonder > if people don't know about that, or are looking to make Firefox -- > specifically -- larger than normal. I'm unclear on what Linux offers these > days, and while I think OS X supports this internally it's not exposed in > any UI. (Apple's preferred route seems to be screen zooming. Which is neat, > I use it all the time and have normal vision.) So I'd be curious to > understand this use-case better. > > I suspect that users indeed are unaware that they can fix this in OS > settings (except on Mac), and if an OS vendor asked the same questions > about the system as a whole, they'd get a similar response. It'd be > interesting for us to confirm that with a followup question about Firefox > vs. apps in general. > > For my part, I too have "normal" (i.e. emmetropic) vision too (although > lately with a bit of presbyopia). Nevertheless, I've long found native UI > affordances to be too small. In the past, I've decreased the resolution of > my display or installed themes with larger icons (in apps that support > themes) to mitigate the issue. These days I mostly just live with it for > native apps. But I almost always zoom web apps. > > Although it's dangerous to extrapolate from a sample of two (especially us > two!) I suspect we aren't isolated cases, and there's a population of folks > with "normal" vision who nonetheless prefer larger affordances for better > readability, easier click targets, etc. and are willing to trade off space > for content or other windows (or, in your case, to use features like screen > zooming). > > Separately from themes, I think it would be a good idea to consider adding > preferences UI for the default zoom-level of page content in Firefox. > > Indeed. Another interesting (but more complex to implement) option would > be to adjust that zoom level to maximize the horizontal usage of space of a > page, zooming more for sites with small font sizes and narrow columns of > content, and less for sites where the default zoom level pushes content > offscreen and creates horizontal scrollbars (or triggers an over-responsive > mobile-friendly rearranging of content). > > -myk > > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changing the style guide's preference for loose over strict equality checks in non-test code
Indeed, a good argument could be made that the old "quirks mode" years of the web were a strong example of the web suffering a lot while learning this very lesson (and modern web standardization processes work pretty hard to try and avoid it). Dan On Fri, May 15, 2015 at 9:47 AM, Martin Thomson wrote: > On Thu, May 14, 2015 at 11:16 PM, Panos Astithas wrote: > > This. From the perspective of a library method validating inputs, I've > > always found it pays off to rely on Postel's principle. > > > Sorry, that's a red flag for me. Postel was wrong. (Search for that > phrase.) > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
