Re: Is super-review still a thing?

[Eric Rescorla]

On Fri, Apr 20, 2018 at 7:03 PM, Dave Townsend 
wrote:

> Presumably it supports multiple reviews for a patch, in which case I think
> we're fine.
>

It does.

-Ekr


> On Fri, Apr 20, 2018 at 3:03 PM Gregory Szorc  wrote:
>
> > On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron 
> wrote:
> >
> > > On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
> > > > For a lot of these patches, my opinion is only really critical for
> > > certain
> > > > architectural aspects, or implementation aspects at a few critical
> > > points.
> > > > There are other reviewers who are perfectly qualified to do a more
> > > detailed
> > > > review of the specifics of the patch, and have more spare cycles to
> > > devote
> > > > to it. Essentially, what's needed from me in these cases is a
> > > super-review,
> > > > which I can do fairly easily, but instead I become a bottleneck for
> the
> > > code
> > > > review as well.
> > > >
> > > > So, for the areas where I have this responsibility, I'd like to
> > > institute a
> > > > policy that certain types of changes need a final super-review from
> me,
> > > but
> > > > should get a detailed code review from another qualified reviewer
> when
> > > that
> > > > makes sense.
> > >
> > > I think it's reasonable to use the super-review flag for this sort
> > > of high-level or design review, at least until we come up with a
> > > better name for it (and make a new flag, and retire the old one).  I
> > > don't think the super-review policy (as written) is meaningful
> > > today.
> >
> >
> > FWIW I'm pretty sure Phabricator won't support the super-review flag. And
> > since we're aiming to transition all reviews to Phabricator...
> > ___
> > 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: Is super-review still a thing?

[Dave Townsend]

Presumably it supports multiple reviews for a patch, in which case I think
we're fine.

On Fri, Apr 20, 2018 at 3:03 PM Gregory Szorc  wrote:

> On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron  wrote:
>
> > On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
> > > For a lot of these patches, my opinion is only really critical for
> > certain
> > > architectural aspects, or implementation aspects at a few critical
> > points.
> > > There are other reviewers who are perfectly qualified to do a more
> > detailed
> > > review of the specifics of the patch, and have more spare cycles to
> > devote
> > > to it. Essentially, what's needed from me in these cases is a
> > super-review,
> > > which I can do fairly easily, but instead I become a bottleneck for the
> > code
> > > review as well.
> > >
> > > So, for the areas where I have this responsibility, I'd like to
> > institute a
> > > policy that certain types of changes need a final super-review from me,
> > but
> > > should get a detailed code review from another qualified reviewer when
> > that
> > > makes sense.
> >
> > I think it's reasonable to use the super-review flag for this sort
> > of high-level or design review, at least until we come up with a
> > better name for it (and make a new flag, and retire the old one).  I
> > don't think the super-review policy (as written) is meaningful
> > today.
>
>
> FWIW I'm pretty sure Phabricator won't support the super-review flag. And
> since we're aiming to transition all reviews to Phabricator...
> ___
> 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: Is super-review still a thing?

[Dave Townsend]

No, super-review has not really been a thing for some time, we should
remove documentation suggesting it is. That said we definitely have room
for this kind of architectural review. Webidl for example already uses
something like this.

On Fri, Apr 20, 2018 at 2:24 PM Kris Maglione  wrote:

> I can't remember the last time I saw a super-review request, but
> it's still documented as a policy[1]. Is it still a thing? Do we
> want it to still be a thing?
>
> The reason that I ask is that I have a problem that I think I
> might be able to solve by co-opting the super-review flag, but I
> don't want to trample on it if we're still using it as
> originally designed.
>
> My problem is essentially that, for a few areas of code, I'm the
> final arbiter, or at least the main blocker, for a lot of large
> or critical architectural or API changes. The upshot of that is
> that I get a lot of review requests for patches in those areas,
> and most of the patches that make it into my queue are large
> and/or complicated. This situation gets exhausting after a
> while. And since people know that I tend to be busy, they also
> avoid flagging me to review smaller patches, even when I really
> *should* look at those patches (and therefore notice issues with
> them only when I read code later).
>
> For a lot of these patches, my opinion is only really critical
> for certain architectural aspects, or implementation aspects at
> a few critical points. There are other reviewers who are
> perfectly qualified to do a more detailed review of the
> specifics of the patch, and have more spare cycles to devote to
> it. Essentially, what's needed from me in these cases is a
> super-review, which I can do fairly easily, but instead I become
> a bottleneck for the code review as well.
>
> So, for the areas where I have this responsibility, I'd like to
> institute a policy that certain types of changes need a final
> super-review from me, but should get a detailed code review from
> another qualified reviewer when that makes sense.
>
>
> Does anyone have any objection to this plan? Or any suggestions
> for another way to go about it?
>
> -Kris
>
> [1]: https://www.mozilla.org/en-US/about/governance/policies/reviewers/
> ___
> 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: Is super-review still a thing?

[Tom Ritter]

Does it support the feedback flag?

On Fri, Apr 20, 2018, 5:03 PM Gregory Szorc  wrote:

> On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron  wrote:
>
> > On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
> > > For a lot of these patches, my opinion is only really critical for
> > certain
> > > architectural aspects, or implementation aspects at a few critical
> > points.
> > > There are other reviewers who are perfectly qualified to do a more
> > detailed
> > > review of the specifics of the patch, and have more spare cycles to
> > devote
> > > to it. Essentially, what's needed from me in these cases is a
> > super-review,
> > > which I can do fairly easily, but instead I become a bottleneck for the
> > code
> > > review as well.
> > >
> > > So, for the areas where I have this responsibility, I'd like to
> > institute a
> > > policy that certain types of changes need a final super-review from me,
> > but
> > > should get a detailed code review from another qualified reviewer when
> > that
> > > makes sense.
> >
> > I think it's reasonable to use the super-review flag for this sort
> > of high-level or design review, at least until we come up with a
> > better name for it (and make a new flag, and retire the old one).  I
> > don't think the super-review policy (as written) is meaningful
> > today.
>
>
> FWIW I'm pretty sure Phabricator won't support the super-review flag. And
> since we're aiming to transition all reviews to Phabricator...
> ___
> 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: Intent to implement and ship: same-site cookies

[Francois Marier]

On 09/04/18 07:25 PM, Francois Marier wrote:
> We intend to ship same-site cookies in Firefox 61.

This has now been uplifted and will be shipping in Firefox 60.

Status can be tracked on https://wiki.mozilla.org/Security/SameSiteCookies.

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

Re: Is super-review still a thing?

[Emma Humphries]

I’m away from my computer until the morning, but I think we disabled the 
super-review flag. 

If Kris and David want to draft an architectural review policy that would be 
useful, and we could set up the flags at the right level

> On Apr 20, 2018, at 23:51, L. David Baron  wrote:
> 
>> On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
>> For a lot of these patches, my opinion is only really critical for certain
>> architectural aspects, or implementation aspects at a few critical points.
>> There are other reviewers who are perfectly qualified to do a more detailed
>> review of the specifics of the patch, and have more spare cycles to devote
>> to it. Essentially, what's needed from me in these cases is a super-review,
>> which I can do fairly easily, but instead I become a bottleneck for the code
>> review as well.
>> 
>> So, for the areas where I have this responsibility, I'd like to institute a
>> policy that certain types of changes need a final super-review from me, but
>> should get a detailed code review from another qualified reviewer when that
>> makes sense.
> 
> I think it's reasonable to use the super-review flag for this sort
> of high-level or design review, at least until we come up with a
> better name for it (and make a new flag, and retire the old one).  I
> don't think the super-review policy (as written) is meaningful
> today.
> 
> -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)
> ___
> 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: Is super-review still a thing?

[Gregory Szorc]

On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron  wrote:

> On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
> > For a lot of these patches, my opinion is only really critical for
> certain
> > architectural aspects, or implementation aspects at a few critical
> points.
> > There are other reviewers who are perfectly qualified to do a more
> detailed
> > review of the specifics of the patch, and have more spare cycles to
> devote
> > to it. Essentially, what's needed from me in these cases is a
> super-review,
> > which I can do fairly easily, but instead I become a bottleneck for the
> code
> > review as well.
> >
> > So, for the areas where I have this responsibility, I'd like to
> institute a
> > policy that certain types of changes need a final super-review from me,
> but
> > should get a detailed code review from another qualified reviewer when
> that
> > makes sense.
>
> I think it's reasonable to use the super-review flag for this sort
> of high-level or design review, at least until we come up with a
> better name for it (and make a new flag, and retire the old one).  I
> don't think the super-review policy (as written) is meaningful
> today.


FWIW I'm pretty sure Phabricator won't support the super-review flag. And
since we're aiming to transition all reviews to Phabricator...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is super-review still a thing?

[L. David Baron]

On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
> For a lot of these patches, my opinion is only really critical for certain
> architectural aspects, or implementation aspects at a few critical points.
> There are other reviewers who are perfectly qualified to do a more detailed
> review of the specifics of the patch, and have more spare cycles to devote
> to it. Essentially, what's needed from me in these cases is a super-review,
> which I can do fairly easily, but instead I become a bottleneck for the code
> review as well.
> 
> So, for the areas where I have this responsibility, I'd like to institute a
> policy that certain types of changes need a final super-review from me, but
> should get a detailed code review from another qualified reviewer when that
> makes sense.

I think it's reasonable to use the super-review flag for this sort
of high-level or design review, at least until we come up with a
better name for it (and make a new flag, and retire the old one).  I
don't think the super-review policy (as written) is meaningful
today.

-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

Is super-review still a thing?

[Kris Maglione]

I can't remember the last time I saw a super-review request, but 
it's still documented as a policy[1]. Is it still a thing? Do we 
want it to still be a thing?


The reason that I ask is that I have a problem that I think I 
might be able to solve by co-opting the super-review flag, but I 
don't want to trample on it if we're still using it as 
originally designed.


My problem is essentially that, for a few areas of code, I'm the 
final arbiter, or at least the main blocker, for a lot of large 
or critical architectural or API changes. The upshot of that is 
that I get a lot of review requests for patches in those areas, 
and most of the patches that make it into my queue are large 
and/or complicated. This situation gets exhausting after a 
while. And since people know that I tend to be busy, they also 
avoid flagging me to review smaller patches, even when I really 
*should* look at those patches (and therefore notice issues with 
them only when I read code later).


For a lot of these patches, my opinion is only really critical 
for certain architectural aspects, or implementation aspects at 
a few critical points. There are other reviewers who are 
perfectly qualified to do a more detailed review of the 
specifics of the patch, and have more spare cycles to devote to 
it. Essentially, what's needed from me in these cases is a 
super-review, which I can do fairly easily, but instead I become 
a bottleneck for the code review as well.


So, for the areas where I have this responsibility, I'd like to 
institute a policy that certain types of changes need a final 
super-review from me, but should get a detailed code review from 
another qualified reviewer when that makes sense.



Does anyone have any objection to this plan? Or any suggestions 
for another way to go about it?


-Kris

[1]: https://www.mozilla.org/en-US/about/governance/policies/reviewers/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Firefox data engineering newsletter, Q1 2018

[Georg Fritzsche]

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 turnaround times faster, we now support adding scalars in
artifact builds

and will soon extend this to events
.

Following the recent Firefox data preferences changes, we adopted Telemetry

to only differentiate between "release" and "prerelease" data.

This also impacted the 

Intent to unship nsIDOMEvent

[Boris Zbarsky]

Building on Nika's awesome work in bug 1444991, I just landed some 
patches to remove nsIDOMEvent (bug 1455052).  xpidl should now use 
"webidl Event"; C++ should use "mozilla::dom::Event".


Please do not use Ci.nsIDOMEvent in JS code.  I have fixed the m-c uses 
I found.


If you need Event in a non-window scope, 
Cu.importGlobalProperties(["Event"]) will provide it.


-Boris

P.S.  Generally speaking, we're aiming to remove nsIDOM* things.  We're 
down from 183 such files on esr52 to 108 on release, to 76 on beta, to 
44 on m-c.  So it's going pretty well.  ;)

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

Re: Soft code freeze for Firefox 61 starts April 26

[Ryan VanderMeulen]

Just a reminder that this is now less than a week away. Please be mindful
of any large/risky patches targeting 61 as time is running low to land them
before the soft freeze begins.

Thanks,
Ryan

On Thu, Apr 12, 2018 at 10:56 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> Hi all,
>
> On April 26th, we will be merging Firefox 61 from mozilla-central to beta
> for
> the first time. In order to avoid invalidating the testing we get out of
> late
> nightly and the early Developer Edition builds and to ensure that we can
> roll
> out Beta 61 to a wider audience with confidence, we'd like to ask that any
> risky changes be avoided from April 26th until after the version bump to
> 62 on
> May 7th.
>
> Some reminders for during the soft code freeze:
> Do:
> - Be ready to backout patches that cause crash spikes, new crashes,
>   severe regressions
> - Monitor new regressions and escalate merge blockers
> - Support release management by prioritizing fixing of merge blockers
>
> Do Not:
> - Land a risky patch or a large patch
> - Land new features (that affects the current nightly version) — be
>   mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead
>   to unexpected CI results
> - Flip prefs that enable new Features that were untested in Nightly cycle
> - Plan to kick off new experiments that might impact a feature's merge
>   readiness
>
> Please let us know if you have any questions/concerns.
>
> Thanks,
> Release Management Team
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Hey! Can you please briefly try this test build...

[Mike Conley]

Solid tip from Xidorn. For the lazy, that command is:

./mach mozregression --launch b5a512aaef49 --repo try

On 2018-04-20 9:53 AM, Xidorn Quan wrote:
> FWIW, I always find that the easiest way to run some build is using 
> mozregression's "Run a single build", which would take care of downloading, 
> unpacking, and creating a new profile for it.
> 
> In this case, you'd want to choose "try" and input changeset "b5a512aaef49".
> 
> - Xidorn
> 
> On Fri, Apr 20, 2018, at 6:12 PM, Carl Corcoran wrote:
>>  Hello everyone! I need some help gathering some real-world data about DLLs
>> that get loaded into Firefox on Windows (re bug 1435827). I have created a
>> test build that outputs runtime DLL information to a text file on disk, and
>> I'd like to see what results you get on your machine(s).
>>
>> If you have already helped me with this, no need to do it again.
>>
>> So when you have a moment, can you please:
>>
>>1. Make sure you have a c:\temp directory
>>2. Download target.zip from either of the links below, extract, & run
>>firefox.exe
>>   - for 64-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
>>   174270831=try
>>   - for 32-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
>>   174270829=try
>>3. Run it at least for a while. The idea is to get a profile of DLLs
>>that are loaded into the process.
>>4. Find the results at c:\temp\ffmodules.txt, and email them to me at
>>ccorco...@mozilla.com
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



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

Re: Hey! Can you please briefly try this test build...

[Xidorn Quan]

FWIW, I always find that the easiest way to run some build is using 
mozregression's "Run a single build", which would take care of downloading, 
unpacking, and creating a new profile for it.

In this case, you'd want to choose "try" and input changeset "b5a512aaef49".

- Xidorn

On Fri, Apr 20, 2018, at 6:12 PM, Carl Corcoran wrote:
>  Hello everyone! I need some help gathering some real-world data about DLLs
> that get loaded into Firefox on Windows (re bug 1435827). I have created a
> test build that outputs runtime DLL information to a text file on disk, and
> I'd like to see what results you get on your machine(s).
> 
> If you have already helped me with this, no need to do it again.
> 
> So when you have a moment, can you please:
> 
>1. Make sure you have a c:\temp directory
>2. Download target.zip from either of the links below, extract, & run
>firefox.exe
>   - for 64-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
>   174270831=try
>   - for 32-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
>   174270829=try
>3. Run it at least for a while. The idea is to get a profile of DLLs
>that are loaded into the process.
>4. Find the results at c:\temp\ffmodules.txt, and email them to me at
>ccorco...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Hey! Can you please briefly try this test build...

[Carl Corcoran]

 Hello everyone! I need some help gathering some real-world data about DLLs
that get loaded into Firefox on Windows (re bug 1435827). I have created a
test build that outputs runtime DLL information to a text file on disk, and
I'd like to see what results you get on your machine(s).

If you have already helped me with this, no need to do it again.

So when you have a moment, can you please:

   1. Make sure you have a c:\temp directory
   2. Download target.zip from either of the links below, extract, & run
   firefox.exe
  - for 64-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
  174270831=try
  - for 32-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
  174270829=try
   3. Run it at least for a while. The idea is to get a profile of DLLs
   that are loaded into the process.
   4. Find the results at c:\temp\ffmodules.txt, and email them to me at
   ccorco...@mozilla.com

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