removed support for fuzzy() annotations without ranges in reftest manifests

[L. David Baron]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1369941 (which just
landed on autoland) I removed support for fuzzy() and fuzzy-if()
annotations *without* numeric ranges in reftest manifests.

This means that what used to be written as:
  fuzzy(1,8) == ...
  fuzzy-if(Android,3,50) == ...
now needs to be written (but see next paragraph!) as:
  fuzzy(0-1,0-8) == ...
  fuzzy-if(Android,0-3,0-50) == ...
to keep the same behavior and indicate that the lower bound of the
range is a 0 color component difference, and 0 pixels differing.

However, the reason for this change is that I actually prefer that
you *not* use ranges with 0s in them.  In particular, when tests are
failing in a minor but non-intermittent way (e.g., due to an
antializing bug), it is generally better to annotate them in a
stricter way, such as:
  fuzzy-if(Android,3-3,50-50)
to indicate that the expectation is that on Android, there will be
exactly 50 pixels differing, with a max color component difference
of exactly 3.  This means that if the difference goes away (or gets
smaller), we'll get an unexpected pass message that will tell us
that we need to change the fuzzy() annotation, and that change in
annotation will in turn mean that we'll get a test failure if it
regresses later.

For more details, see the reftest documentation, the updated verson
of which is currently only on autoland, i.e.:
https://hg.mozilla.org/integration/autoland/file/tip/layout/tools/reftest/README.txt#l117

(At some point in the future it may make sense to add back the
syntax without ranges, but with a different meaning, where 8 means
the range 8-8 rather than the range 0-8.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using clang-cl to ship Windows builds

[Stuart Philp]

That is fantastic, lots of nice wins!

On Tue, Aug 21, 2018 at 6:02 PM, David Major  wrote:

> A quick update about performance: ThinLTO and PGO were enabled for our
> clang-cl builds over the last few weeks. These optimizations have
> cancelled the previous regressions and brought clang well ahead of
> MSVC: https://treeherder.mozilla.org/perf.html#/compare?
> originalProject=try=2adb3cb404ad&
> newProject=try=5336df94a9ce=1
> To call out a few: Speedometer scores increased by 6% on Win64 and 12%
> on Win32, and the most dramatic improvement was displaylist_mutate at
> 27%!
>
> As far as I'm aware, no blockers have come up and clang-cl is still
> looking good for the 63 train.
>
> On Tue, Jul 10, 2018 at 4:29 PM David Major  wrote:
> >
> > Bug 1443590 is switching our official Windows builds to use clang-cl
> > as the compiler.
> >
> > Please keep an eye out for regressions and file a blocking bug for
> > anything that might be fallout from this change. I'm especially
> > interested in hearing about the quality of the debugging experience.
> >
> > It's possible that the patch may bounce and we'll go back and forth to
> > MSVC for a while. You can check your build's compiler at
> > `about:buildconfig`. Treeherder is running an additional set of MSVC
> > jobs on mozilla-central to make sure we can fall back to a green MSVC
> > if needed.
> >
> > Watch for more toolchain changes to come. The next steps after this
> > will be to switch to lld-link and enable ThinLTO. That will open the
> > door to a cross-language LTO that could inline calls between Rust and
> > C++. In the longer term we can look into cross-compiling from Linux.
> >
> > But for now, shipping our most-used platform with an open-source
> > compiler is a huge milestone in and of itself. Big thanks to everyone
> > who has contributed to this effort on the Mozilla side, and also big
> > thanks to the developers of LLVM and Chromium who helped make clang on
> > Windows a realistic possibility.
> ___
> 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: Using clang-cl to ship Windows builds

[David Major]

A quick update about performance: ThinLTO and PGO were enabled for our
clang-cl builds over the last few weeks. These optimizations have
cancelled the previous regressions and brought clang well ahead of
MSVC: 
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=2adb3cb404ad=try=5336df94a9ce=1
To call out a few: Speedometer scores increased by 6% on Win64 and 12%
on Win32, and the most dramatic improvement was displaylist_mutate at
27%!

As far as I'm aware, no blockers have come up and clang-cl is still
looking good for the 63 train.

On Tue, Jul 10, 2018 at 4:29 PM David Major  wrote:
>
> Bug 1443590 is switching our official Windows builds to use clang-cl
> as the compiler.
>
> Please keep an eye out for regressions and file a blocking bug for
> anything that might be fallout from this change. I'm especially
> interested in hearing about the quality of the debugging experience.
>
> It's possible that the patch may bounce and we'll go back and forth to
> MSVC for a while. You can check your build's compiler at
> `about:buildconfig`. Treeherder is running an additional set of MSVC
> jobs on mozilla-central to make sure we can fall back to a green MSVC
> if needed.
>
> Watch for more toolchain changes to come. The next steps after this
> will be to switch to lld-link and enable ThinLTO. That will open the
> door to a cross-language LTO that could inline calls between Rust and
> C++. In the longer term we can look into cross-compiling from Linux.
>
> But for now, shipping our most-used platform with an open-source
> compiler is a huge milestone in and of itself. Big thanks to everyone
> who has contributed to this effort on the Mozilla side, and also big
> thanks to the developers of LLVM and Chromium who helped make clang on
> Windows a realistic possibility.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Local Windows builds to use clang-cl by default

[David Major]

Hi,

Local Windows builds will use clang-cl and lld-link by default as of
bug 1483835. This will make your builds match what has been shipping
on Nightly for the last several weeks, and help avoid the occasional
MSVC bustage that sneaks in now that those builds are tier-2.

If you already ran `mach bootstrap` for the recent cbindgen changes,
you'll already have an up-to-date clang and there's no further action
required.

If you need to revert to the Microsoft toolchain, you can put one or
both of these lines in your mozconfig (but please get in touch and
tell me why you needed to):
export CC=cl
export LINKER=link

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

[IMPORTANT] QA Firefox 64 feature testing pi-requests deadline is August 29

[Tom Grabowski]

Hi,

Similar to what QA did for previous Firefox feature testing prioritization
,
we would like to do the same for Fx64. In order to help with the
process, *please
submit your pi-request
 by August 29. *This
is needed to assure QA will be involved in your feature development work
for the Nightly 64 cycle.


*Q: What happens after the deadline?*
A: After the deadline QA will come back with a prioritized list of work
that represents what we are committing to for the next cycle. We want to
ensure this list matches eng and product expectations.

*Q: What if I miss the deadline?*
A: We reserve the right to say that we can't pick up work for late requests
in the current cycle. You can still develop and execute your own test plan
or defer the work to the following cycle.

*Q: What about unknown or unexpected requests? What if there is a business
reason for a late request? What do we do with experiments and System
Add-ons?*
A: In order to remain flexible, we will keep some percentage of time open
for requests like these.

*Q: There's no way I'm going to remember to do this. *
A: Do it now! I'll also send out a reminder next week.

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

Re: PSA - Planning to enable VR service process on desktop (Linux, macOS, and Windows)

[kgilbert]

On Monday, August 20, 2018 at 4:16:56 PM UTC-7, Kip Gilbert wrote:
> Hello all,
> 
> In order to unblock sandboxing of the GPU process and efforts to re-enable 
> macOS WebVR support, we are moving the VR device interfacing code to its own 
> “VR Service” process.  This process will only be launched when a user 
> accesses a WebVR site.
> 
> The bugs to enable this by default will flip two prefs:
> 
> Bug 1476092 (Enable the VR process by default)
> Bug 1473399 (Enable VRService thread by default)
> 
> This change will not affect the WebVR API or otherwise be user facing.
> 
> I expect to flip these prefs before the upcoming soft-freeze (2018-08-23).
> 
> Any feedback is welcome, thanks!
> 
> Cheers,
> 
>   *   Kearwood “Kip” Gilbert

Addendum - We've decided to flip the prefs after the merge date and let this 
run a full cycle in Nightly.  FF64 would be the first with the VR process 
enabled by default.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Windows support for moz-phab and Arcanist

[Mark Côté]

Quick update:

- Landed Windows 10 support for moz-phab (our commit-series-friendly
Arcanist wrapper).
- Improved installation and usage instructions for moz-phab.
- Referenced moz-phab from our Phabricator user guide (mainly just a link
to moz-phab's README).
- Published our own Arcanist installation docs for Windows 10 (
https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html). It is
a clear, step-by-step guide with more details than the official docs.

Our current priority for moz-phab is git support. As an aside,
commit-series support for Lando is progressing through review (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1457525 and its blocker bugs).

You can find moz-phab at https://github.com/mozilla-conduit/review.

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

Re: PSA: mercurial-setup becomes vcs-setup and adds support for git

[Mike Hommey]

On Tue, Aug 21, 2018 at 01:26:27PM +0200, Jean-Yves Avenard wrote:
> Hi.
> 
> This is awesome, upgrading and configuring cinnabar had always been a sore 
> point
> 
> But I just noticed that it appears to pull from git-cinnabar master branch…
> 
> I had to run bootstrap on android yesterday, which upgraded git-cinnabar 
> (requiring a git upgrade)
> and had to run it again today. which too requires a git upgrade
> 
> git upgrade takes a significant time.
> 
> Wouldn’t it be better to follow the release branch instead of master?

The master branch is now the default branch and recommended to use from
0.5 onwards. It won't receive any change that require a git cinnabar
upgrade (until next "minor" version change, aka 0.6).

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

Re: PSA: mercurial-setup becomes vcs-setup and adds support for git

[Jean-Yves Avenard]

Hi.

This is awesome, upgrading and configuring cinnabar had always been a sore point

But I just noticed that it appears to pull from git-cinnabar master branch…

I had to run bootstrap on android yesterday, which upgraded git-cinnabar 
(requiring a git upgrade)
and had to run it again today. which too requires a git upgrade

git upgrade takes a significant time.

Wouldn’t it be better to follow the release branch instead of master?

JY

> On 17 Aug 2018, at 9:50 am, Panos Astithas  wrote:
> 
> Hi all,
> 
> since bug 1257478 landed in m-c earlier today, you should now be using 'mach 
> vcs-setup' instead of 'mach mercurial-setup'. Nothing else changes in your 
> workflow (e.g. 'mach mercurial-setup -u' becomes 'mach vcs-setup -u') and the 
> spell checker will suggest vcs-setup if you try to use mercurial-setup.
> 
> If you are a git-cinnabar user, your workflow is now supported. 'mach 
> vcs-setup --git' will fetch the latest recommended version of git-cinnabar 
> and configure it for you. The --update-only flag is also available for git, 
> so it would be a good idea to run 'mach vcs-setup --git --update-only' (or 
> 'mach vcs-setup -gu') every now and then to make sure everything is up to 
> date.
> 
> 'mach bootstrap' will also offer to update and configure your git-cinnabar 
> environment if a git checkout is detected. 
> 
> Cheers,
> Panos
> 
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev



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