Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

2019-01-07 Thread Randell Jesup
>* do we turn off builds as well?  I had proposed just the tests, if we decide 
>to turn off talos it would make sense to turn off builds.

Would turning off opt builds cause problems if you want to mozregression
an opt build?  And would this be an issue?  (obviously it might be for
opt-only failures, or trying to verify if a regression identified in
mozregression for PGO was a PGO bug or now, though that could be checked
at the cost of a build or 4 even if we don't build opt, probably).

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: nasm will soon become a build dependency

2019-01-07 Thread Thomas Daede
On 12/21/18 3:09 PM, Mike Hommey wrote:
> On Fri, Dec 21, 2018 at 04:21:03PM -0500, Kartikaya Gupta wrote:
>> I would certainly prefer this, and having this work smoothly would
>> also be good for new contributors. Having to build and install extra
>> packages is always a hassle.
> 
> It's a hassle downstream too.
> 
> Mike

Not sure what I can do for downstream though - afaik most Linux distros
don't use any of our toolchain builds?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

2019-01-07 Thread Aki Sasaki
+1.

The goal of shippable builds is twofold:

1. to make sure opt builds+tests, or similar (artifact builds?) answer the
question "is my commit good?" as fast as possible, and
2. to make sure shippable builds+tests answer the question "are these
binaries correct and ready to ship, if we decide to ship this revision?"

I agree that we should run a full suite of tests against shippable builds,
which probably includes things like performance testing.
We still need some class of builds+tests that answer the question "is my
commit good?" quickly. If debug builds are sufficient for the most part,
and opt builds+tests on try fill in the gaps, then yes. (That appears to be
what this thread is largely about.) If not, I could see us having at least
some subset of tests running against opt or artifact builds.

If we switch talos to PGO now, we'll probably switch them to shippable
builds at some point in the near future.


On Thu, Jan 3, 2019 at 8:45 AM Andrew Halberstadt  wrote:

> CC Callek
>
> How will this interact with the "shippable builds" project that Callek
> posted
> about awhile back? My understanding is there's a high probability PGO is
> going away. Would it make sense to wait for that to project to wrap up?
>
> -Andrew
>
> On Thu, Jan 3, 2019 at 11:20 AM jmaher  wrote:
>
> > I would like to propose that we do not run tests on linux64-opt,
> > windows7-opt, and windows10-opt.
> >
> > Why am I proposing this:
> > 1) All test regressions that were found on trunk are mostly on debug, and
> > in fewer cases on PGO.  There are no unique regressions found in the
> last 6
> > months (all the data I looked at) that are exclusive to OPT builds.
> > 2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO
> > builds, we do not run tests on plan OPT builds
> > 3) This will reduce the jobs (about 16%) we run which in turn reduces,
> cpu
> > time, money spent, turnaround time, intermittents, complexity of the
> > taskgraph.
> > 4) PGO builds are very similar to OPT builds, but we add flags to
> generate
> > profile data and small adjustments to build scripts behind MOZ_PGO flag
> > in-tree, then we launch the browser, collect data, and repack our
> binaries
> > for faster performance.
> > 5) We ship PGO builds, not OPT builds
> >
> > What are the risks associated with this?
> > 1) try server build times will increase as we will be testing on PGO
> > instead of OPT
> > 2) we could miss a regression that only shows up on OPT, but if we only
> > ship PGO and once we leave central we do not build OPT, this is a very
> low
> > risk.
> >
> > I would like to hear any concerns you might have on this or other areas
> > which I have overlooked.  Assuming there are no risks which block this, I
> > would like to have a decision by January 11th, and make the adjustments
> on
> > January 28th when Firefox 67 is on trunk.
> > ___
> > 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: Rust code coverage

2019-01-07 Thread Henri Sivonen
On Fri, Jan 4, 2019 at 2:54 PM Marco Castelluccio
 wrote:
> Hi everyone,
> we have recently enabled collecting code coverage for Rust code too,

Nice!

> running Rust tests in coverage builds.

Does this mean running cargo test for each crate under
third_party/rust, running Firefox test suites or both?

As for trying to make sense of what the numbers mean:

Is the coverage ratio reported on lines attributed at all in ELF as
opposed to looking at the number of lines in the source files?

What kind of expectations one should have on how the system measures
coverage for code that gets inlined?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform