Re: [Update] Revert RESOLVED:INACTIVE State

[Erin Lancaster]

Of course, happy to get us back to a good place and very sorry for all of
the inconvenience. We haven't had any further requests for exclusions for
the revert: https://bugzilla.mozilla.org/show_bug.cgi?id=1464312. It would
be helpful to get any other requests in asap.

Dylan will be checking the ticket first thing Tuesday morning ET and will
then get going with final review/testing. Many thanks to Dylan and to Mark
for all their support.

Erin

On Sat, May 26, 2018 at 7:43 PM, Boris Zbarsky  wrote:

> On 5/25/18 5:07 PM, Erin Lancaster wrote:
>
>> Here’s where we are with timing/process for the revert:
>>
>
> Erin,
>
> Thank you for all the work you've put in on this.  I know it hasn't been
> easy dealing with this, and I really appreciate it.
>
> -Boris
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing tinderbox-builds from archive.mozilla.org

[Chris AtLee]

On Sun, 20 May 2018 at 19:40, Karl Tomlinson  wrote:

> On Fri, 18 May 2018 13:13:04 -0400, Chris AtLee wrote:

> > IMO, it's not reasonable to keep CI builds around forever, so the
question
> > is then how long to keep them? 1 year doesn't quite cover a full ESR
cycle,
> > would 18 months be sufficient for most cases?
> >
> > Alternatively, we could investigate having different expiration policies
> > for different type of artifacts. My assumption is that the Firefox
binaries
> > for the opt builds are the most useful over the long term, and that
other
> > build configurations and artifacts are less useful. How accurate is that
> > assumption?

> Having a subset of builds around for longer would be more useful
> to me than having all builds available for a shorter period.

> The nightly builds often include large numbers of changesets,
> sometimes collected over several days, and so it becomes hard to
> identify which code change modified a particular behavior.

> I always use opt builds for regression testing, and so your
> assumption is consistent with my experience.

> I assume there are more pgo builds than nightly builds, but fewer
> than all opt builds.  If so, then having a long expiration policy
> on pgo builds could be a helpful way to reduce storage costs but
> maintain the most valuable builds.

Here's a bit of a strawman proposal...What if we keep the
{mozilla-central,mozilla-inbound,autoland}-{linux,linux64,macosx64,win32,win64}{,-pgo}/
directories in tinderbox-builds for now, and delete all the others. Does
that cover the majority of the use cases for wanting to access these old
builds?

I'm guessing the historical builds for old esr branches aren't useful now.
Nor are the mozilla-aurora, mozilla-beta, mozilla-release, or b2g-inbound
builds.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Update] Revert RESOLVED:INACTIVE State

[Boris Zbarsky]

On 5/25/18 5:07 PM, Erin Lancaster wrote:

Here’s where we are with timing/process for the revert:


Erin,

Thank you for all the work you've put in on this.  I know it hasn't been 
easy dealing with this, and I really appreciate it.


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

Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Jet Villegas]

The New checker features look really promising. Yes, more of this stuff in
C++ is very welcome.

On Wed, May 23, 2018 at 1:53 PM, Chris Peterson 
wrote:

> On 2018-05-23 1:35 PM, Botond Ballo wrote:
>
>> There is also work being done in this area outside the formal
>> standards process, in the form of the C++ Core Guidelines [2] (some of
>> which can be checked statically) and the accompanying Guideline
>> Support Library [3], and in the form of Microsoft's lifetime checker
>> [4], though that seems to be progressing very slowly, and even though
>> I ask for an update at every meeting, I haven't seen much of substance
>> there.
>>
>
> Facebook's Infer static analysis tool is adding more deeper checks for
> ownership lifetimes. They describe it as a "rough prototype of Rust-style
> borrow checker for C++."
>
> https://github.com/facebook/infer/releases/tag/v0.14.0
>
> ___
> 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: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Jet Villegas]

The continued work on the 2D GFx API as a C++ standard is concerning. Since
we're sending a GFx engineer to the committee, and AFAIK we're not going to
use such an API to build our GFx stack, the arguments against continued
development seem very compelling:

   -

   there are no clear users or demand for this feature from the community,
   -

   there is higher impact work that a 2D drawing library depends on,
   -

   there is higher impact work in general, and
   -

   the committee does not have infinite time,

I'd rather see the committee focus on things like object lifetime
management so we don't have to port everything to Rust just to get basic
memory safety guarantees. How much leverage do we have to push on that?

Thanks,

--Jet




On Tue, May 22, 2018 at 3:35 PM, Botond Ballo  wrote:

> Hi everyone!
>
> The next meeting of the C++ Standards Committee will be June 4-9 in
> Rapperswil, Switzerland.
>
> This is going to be a pivotal meeting, with go / no-go decisions
> expected for several highly-anticipated C++20 features, including a
> subset of Modules; Coroutines; Ranges; and "natural syntax" Concepts /
> abbreviated function templates. A discussion of whether or not to
> continue efforts to standardize 2D Graphics is also scheduled (see
> arguments for [1] and against [2]). In addition, work will continue on
> various Technical Specifications that are in flight (including,
> notably, Reflection), and processing the large influx of new language
> and library feature proposals.
>
> If you're curious about the state of C++ standardization, I encourage
> you to check out my blog posts where I summarize each meeting in
> detail (most recent one here [3]), and the list of proposals being
> considered by the committee (new ones since the last meeting can be
> found here [4] and here [5]).
>
> I will be attending this meeting, hanging out in the Evolution Working
> Group (where new language features are discussed at the design level)
> as usual. As always, if there's anything you'd like me to find out for
> you at the meeting, or any feedback you'd like me to communicate,
> please let me know!
>
> Finally, I encourage you to reach out to me if you're thinking of
> submitting a proposal to the committee. I'm always happy to help with
> formulating and, if necessary, presenting a proposal.
>
> Cheers,
> Botond
>
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0988r0.pdf
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html
> [3] https://botondballo.wordpress.com/2018/03/28/trip-report-c-
> standards-meeting-in-jacksonville-march-2018/
> [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-02
> [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-04
> ___
> 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: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Jet Villegas]

On Wed, May 23, 2018 at 1:35 PM, Botond Ballo  wrote:

> On Wed, May 23, 2018 at 4:05 PM, Jet Villegas 
> wrote:
> > I'd rather see the committee focus on things like object lifetime
> management
> > so we don't have to port everything to Rust just to get basic memory
> safety
> > guarantees. How much leverage do we have to push on that?
>
> I assume you mean "push for better object lifetime management" rather
> than "push against the 2D graphics proposal".
>

Yes, but please remind folks that Firefox already works with Cairo 2D and
we've made our implementation available for all :-)


> The only current proposal that I'm aware of in this area is P0936R0
> ("Bind Returned/Initialized Objects to the Lifetime of Parameters")
> [1]. This aims to extend C++'s lifetime extension rules to "see
> through" suitably annotated function / constructor calls, such that
> objects bound to parameters of such a function / constructor are kept
> alive for the lifetime of the return value / constructed object (so
> the annotation basically means "this function returns an object /
> constructs an object that refers to its parameters, and therefore that
> object should not outlive the parameters").
>
>
That actually sounds like a good thing to have. We'll continue to push on
Rust but still good to tighten up existing C++ code over time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Update on rustc/clang goodness

[Anthony Jones]

  
  
You may already know that the Low-Level Tools team support important tools and code infrastructure. Lately we’ve also been improving our rustc/clang (LLVM) story and I’d like bring everyone up to date.

There are a lot of important and interesting things going on:


  Michael Woerister and Nathan Froyd recently (mid-March) enabled Rust incremental compilation for Firefox developers
  Michael is experimenting with cross language inlining (rustc/clang) using LTO
  
Preliminary results show compiling LLVM with clang and using LTO on rustc improves stylo compilation time by around 15%
LTO requires more work to support Firefox
  
  Nick Nethercote has started speeding up rustc and has already had a number of wins
  David Major has got Windows clang builds working with green tests
  
LTO is still buggy (but works well enough to run benchmarks) and PGO won’t run on Windows
Win32 - clang with LTO w/o PGO is marginally faster than MSVC with LTO/PGO
Win64 - clang with LTO w/o PGO is ~5-10% slower than MSVC with LTO/PGO
Windows users can build locally with clang
  
  Mike Hommey is tracking improvements and regressions in the Rust compiler (performance regression, crash reporting and more crash reporting)
  Tom Tromey is continuing to work on first class Rust support in GDB and LLDB


Ultimately, I’d like to see us standardise on clang on all platforms because it makes Rust/C++ integration better as well as making things simpler for developers and build system maintainers. We’ll get more done if we make our own lives simpler.

I have some specific requests:


  Let me know if you have specific Firefox cases where Rust is slowing you down
  Cross language inlining is coming - avoid duplication between Rust and C++ 
  Start doing your developer builds with clang

Anthony


  

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

Re: Firefox data engineering newsletter, Q1 2018

[Susheel Daswani]

Hi Georg, thanks for rolling this up! As you know Android / Mobile is a
huge focus for all of Mozilla in 2018 - can you please call out which of
your 2018 focus areas incorporate improvements for Android / Mobile?

On Wed, Apr 18, 2018 at 11:20 AM, Georg Fritzsche 
wrote:

> As the Firefox data engineering teams we provide core tools for using data
> to other teams. This spans from collection through *Firefox Telemetry*,
> storage & processing in our *Data Platform* to making data available in *Data
> Tools*.
>
> To make new developments more visible we aim to publish a quarterly
> newsletter. As we skipped one, some important items from Q4 are also
> highlighted this time.
>
> This year our teams are putting their main focus on:
>
>-
>
>Making experimentation easy & powerful.
>-
>
>Providing a low-latency view into product release health.
>-
>
>Making it easy to work with events end-to-end.
>-
>
>Addressing important user issues with our tools.
>
>
> *Usage improvements*
>
> Last year we started to investigate how our various tools are used by
> people working on Firefox in different roles. From that we started
> addressing some of the main issues users have.
>
> Most centrally, the Telemetry portal  is
> now the main entry point to our tools, documentation and other resources.
> When working with Firefox data you will find all the important tools linked
> from there.
>
> We added the probe dictionary
>  to make it easy to find
> what data we have about Firefox usage.
>
> For STMO , our Redash instance, we 
> deployed
> a major UI refresh
> 
> from the upstream project.
>
> There is new documentation on prototyping
> 
> and optimizing
>  STMO
> queries.
>
> Our data documentation  saw many
> other updates, from cookbooks on how to see your own pings
>  and sending
> new pings  to
> adding more datasets
> . We
> also added documentation on how our data pipeline works
> .
>
>
> *Enabling experimentation*
>
> For experimentation, we have focused on improving tooling. Test Tube
>  will soon be our main
> experiment dashboard, replacing experiments viewer. It displays the results
> of multivariant experiments that are being conducted within Firefox.
>
> We now have St. Moab  as a toolkit for
> automatically generating experiment dashboards.
>
>
> *Working with event data*
>
> To make working with events easier, we improved multiple stages in the
> pipeline. Our documentation has an overview
> 
> of the data flow.
>
> On the Firefox side, events can now be recorded through the events API
> ,
> from add-ons
> ,
> and whitelisted Firefox content
> .
> From Firefox 61, all recorded events are automatically counted into
> scalars , to easily
> get summary statistics.
>
> Event data is available for analysis in Redash in different datasets
> .
> We can now also connect more event data to Amplitude
> , a product analytics tool. A connection for some
> mobile events to Amplitude is live, for Firefox Desktop events it will be
> available soon.
>
>
> *Low-latency release health data*
>
> To enable low-latency views into release health data, we are working on
> improving Mission Control ,
> which will soon replace arewestableyet.com
> .
>
> It has new features
>  that
> enable comparing quality measures like crashes release-over-release across
> channels.
>
>
> *Firefox Telemetry tools*
>
> For Firefox instrumentation we expanded on the event recording APIs
> .
> To make build