[IMPORTANT] Submit your PI Requests for Firefox 69 QA feature testing by May 31

2019-05-28 Thread Tom Grabowski
Similar to what QA did for previous Firefox feature testing prioritization
,
we would like to do the same for Fx69. In order to help with the process,
please *submit your pi-request
*
by *May 31*. This is
needed to assure QA will be involved in your feature development work for
the 69 cycle. Kindly ensure to update the *Priority of the PI request *(High,
Medium, Low) as during feature prioritization process, this will be
factored in to ensure critical features have sufficient resources assigned.

Please note that the *Feature technical documentation* needs to be ready
before *June 14*, so that QA has enough time to design the test plan.
Please fill out the Feature Technical Documentation Guidelines Template

and share with the QA owner or add the link in the PI request in JIRA. For*
features that require Nightly testing*, please provide documentation *as
soon as possible*. QA cannot start working on your feature without
documentation.

*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. If the work is critical please
follow the Exception approval process


* 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. Such requests need to follow the Exception
approval process


*Q: There's no way I'm going to remember to do this.*
A: Do it now!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Fwd: Enable cargo pipelining to speed up Firefox builds

2019-05-28 Thread Nicholas Nethercote
Hi,

The Rust compiler and cargo have a very new feature called "pipelining".
This feature increases the amount of parallelism available when building a
multi-crate Rust project by overlapping the compilation of dependent crates.

For more details on how it works, and lots of measurements, see this thread:
https://internals.rust-lang.org/t/evaluating-pipelined-rustc-compilation/10199

*Potential speedups*

The speedups seen depend on various factors:
- the structure of your project's crate graph;
- the machine being used (machines with more cores are likely to see bigger
speedups);
- your build configuration (release/opt builds will speed up more than
debug builds).

On my 14-core Linux box some notable speedups of release/opt builds include:
- webrender: 1.27x faster
- cranelift-codegen: 1.20x faster
- Firefox: 1.07x faster (and Firefox is of course mostly C++ code)

On other projects we have seen as high as 1.84x improvement, while some
projects see no speedup at all. At worst, it should make things only
negligibly slower, because it's not doing significant additional work, just
changing the order in which certain things happen.

*How to use pipelining for Firefox*

To try it in Firefox, do the following:
- Do `rustup update nightly` to get a sufficiently recent compiler/cargo
combination.
- Do `rustup default nightly` to set the nightly compiler/cargo as your
default.
- Set the environment variable `CARGO_BUILD_PIPELINING=true`.
- Build Firefox.

If you want to evaluate its effectiveness before using it in earnest, you
can use erahm's script, which does a bunch of timings:
https://gist.github.com/EricRahm/d0bcedc0af5fcbd33dbedff497893cee

The script builds Firefox 13 times, so it takes a while to run. It does a
default opt build (`./mach -l build.log build`); you might want to change
it to use your preferred mozconfig file.

*How to use pipelining for other Rust projects*

To try it in other Rust projects, do the following:
- Do `rustup update nightly` to get a sufficiently recent compiler/cargo
combination.
- Do `CARGO_BUILD_PIPELINING=true cargo +nightly build` or something
similar.

*Caveats*

Please note that pipelining is new and still experimental. It seems to work
well but may have bugs. We hope to make it a stable feature soon. Alex
Crichton did the implementation within Cargo and I did the implementation
within rustc; please let us know about any problems.

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