Re: Consider avoiding allSettled in tests (was: Re: Intent to ship: Promise.allSettled)

[Kris Maglione]

On Thu, Oct 31, 2019, 06:02 Jason Orendorff  wrote:

> Ignoring the awaited value here is like using `catch {}` to squelch all
> exceptions, or ignoring the return value of an async function or method, or
> any other expression that produces a Promise. Do we have lints for those
> pitfalls? I'm kind of surprised that there doesn't seem to be a built-in
> ESLint lint for `catch {}`.
>

Some directories have an ESLint rule to disallow empty blocks, which
requires that any empty catch blocks at least contain a comment to justify
them.

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

Re: Upcoming changes to hg.mozilla.org access

[Steve Fink]

On 11/1/19 4:03 PM, Andrew Sutherland wrote:

On 11/1/19 4:39 PM, Kim Moir wrote:
On Nov 14, 2019, we intend to change the permissions associated with 
Level
3 access to revoke direct push access to hg.mozilla.org on 
mozilla-inbound,

mozilla-central, mozilla-beta, mozilla-release and esr repos.


For mozilla-beta, mozilla-release, and esr... does lando know how to 
land to these, or is it the case that landings on these branches are 
done based on the approval flags by people other than the patch author?


I ask because if I create a branch based on the hg unified repo 
"release" tag and then use `moz-phab` to create a review, I assume 
what happens if I try and land with "lando" is that it will try and 
land the commit against mozilla-central and it may succeed if the file 
hasn't changed too much in central versus where it was on the release 
branch. 



I recently encountered this situation too. Perhaps I just haven't read 
the right document, but what is the current procedure for manual backports?


I'm now accustomed to the Magic Backporting van der Fairy doing most of 
my backports for me based on the approval flags. But if a patch doesn't 
apply cleanly then I manually rebase onto the beta and/or esr branch. If 
I can't push those myself, should I manually clear out the Phabricator 
revision ID in the commit message so I can use moz-phab or phabsend to 
create a new phabricator revision? I know those have a repo callsign of 
MOZILLACENTRAL -- does that cover beta and esr too, or is there a 
different callsign to use?


Or should I dig out bzexport and attach the patch to the bug? (That's 
what I did, but I felt like I was leaning on van der Fairy's good graces.)


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

Re: Upcoming changes to hg.mozilla.org access

[Andrew Sutherland]

On 11/1/19 4:39 PM, Kim Moir wrote:

On Nov 14, 2019, we intend to change the permissions associated with Level
3 access to revoke direct push access to hg.mozilla.org on mozilla-inbound,
mozilla-central, mozilla-beta, mozilla-release and esr repos.


For mozilla-beta, mozilla-release, and esr... does lando know how to 
land to these, or is it the case that landings on these branches are 
done based on the approval flags by people other than the patch author?


I ask because if I create a branch based on the hg unified repo 
"release" tag and then use `moz-phab` to create a review, I assume what 
happens if I try and land with "lando" is that it will try and land the 
commit against mozilla-central and it may succeed if the file hasn't 
changed too much in central versus where it was on the release branch.


Andrew

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

Re: Upcoming changes to hg.mozilla.org access

[Kim Moir]

Officially decommissioning m-i will take place after we change the
permissions.  It will remain a read-only repo for historical purposes. No I
don't see a need to run things in CI on m-i beyond that date.
deprecate mozilla-inbound after Lando is used for most mozilla-central
landing
https://bugzilla.mozilla.org/show_bug.cgi?id=1530401

Kim

On Fri, Nov 1, 2019 at 4:56 PM Andrew Halberstadt  wrote:

> Very nice!
>
> Does this mean mozilla-inbound is effectively decommissioned at this
> point? Are there any circumstances it will need to run things in CI beyond
> November 14th?
>
> -Andrew
>
>
> On Fri, Nov 1, 2019 at 4:39 PM Kim Moir  wrote:
>
>> The Engineering Workflow team enabled a hook in July which asked people to
>> provide a reason for directly pushing to hg.mozilla.org.  Since it was
>> enabled, we have seen the number of direct pushes decrease to a few per
>> week.
>>
>> Enabling developers to use standard tools to land reviewed code through a
>> secure pipeline also allows us to enable new workflow capabilities such as
>> running static analyzers, linters, and code formatting tools, while making
>> hg.mozilla.org more secure by reducing the number of people who can
>> access
>> it directly. It also paves the way for decommissioning mozilla-inbound,
>> which will simplify our tree management and reduce infrastructure costs.
>>
>> On Nov 14, 2019, we intend to change the permissions associated with Level
>> 3 access to revoke direct push access to hg.mozilla.org on
>> mozilla-inbound,
>> mozilla-central, mozilla-beta, mozilla-release and esr repos. If you do
>> need a patch landed outside the Phabricator/Lando pipeline such as in the
>> case of bustage, please use the #checkin-needed process
>> https://wiki.mozilla.org/Sheriffing/How_To/Landing_checkin-needed_patches
>> and contact the sheriffs in #sheriffs in Slack or IRC to land your patch.
>>
>> Specific teams will retain direct access to hg.mozilla.org (now called
>> Level 4) such as Sheriffs and Release Management. We expect everyone else
>> to use the Phabricator/Lando pipeline, but exceptions may be granted for
>> special situations with director-level approval. If this applies to you,
>> please follow up with your manager.
>>
>> The Engineering Workflow team is committed to supporting and improving the
>> productivity of developers working on Firefox. If you have questions or
>> need help with tooling, please reach out to us in the #phabricator Slack
>> channel.
>>
>> Kim
>> ___
>> 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 changes to hg.mozilla.org access

[Andrew Halberstadt]

Very nice!

Does this mean mozilla-inbound is effectively decommissioned at this point?
Are there any circumstances it will need to run things in CI beyond
November 14th?

-Andrew


On Fri, Nov 1, 2019 at 4:39 PM Kim Moir  wrote:

> The Engineering Workflow team enabled a hook in July which asked people to
> provide a reason for directly pushing to hg.mozilla.org.  Since it was
> enabled, we have seen the number of direct pushes decrease to a few per
> week.
>
> Enabling developers to use standard tools to land reviewed code through a
> secure pipeline also allows us to enable new workflow capabilities such as
> running static analyzers, linters, and code formatting tools, while making
> hg.mozilla.org more secure by reducing the number of people who can access
> it directly. It also paves the way for decommissioning mozilla-inbound,
> which will simplify our tree management and reduce infrastructure costs.
>
> On Nov 14, 2019, we intend to change the permissions associated with Level
> 3 access to revoke direct push access to hg.mozilla.org on
> mozilla-inbound,
> mozilla-central, mozilla-beta, mozilla-release and esr repos. If you do
> need a patch landed outside the Phabricator/Lando pipeline such as in the
> case of bustage, please use the #checkin-needed process
> https://wiki.mozilla.org/Sheriffing/How_To/Landing_checkin-needed_patches
> and contact the sheriffs in #sheriffs in Slack or IRC to land your patch.
>
> Specific teams will retain direct access to hg.mozilla.org (now called
> Level 4) such as Sheriffs and Release Management. We expect everyone else
> to use the Phabricator/Lando pipeline, but exceptions may be granted for
> special situations with director-level approval. If this applies to you,
> please follow up with your manager.
>
> The Engineering Workflow team is committed to supporting and improving the
> productivity of developers working on Firefox. If you have questions or
> need help with tooling, please reach out to us in the #phabricator Slack
> channel.
>
> Kim
> ___
> 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 changes to hg.mozilla.org access

[Mike Conley]

\o/

I think this is a really good thing. The smaller the surface for people to
land code without sufficient guarantees that it went through a review
mechanism, the better.

Thanks to you and your team for their work!

-Mike

On Fri, 1 Nov 2019 at 16:39, Kim Moir  wrote:

> The Engineering Workflow team enabled a hook in July which asked people to
> provide a reason for directly pushing to hg.mozilla.org.  Since it was
> enabled, we have seen the number of direct pushes decrease to a few per
> week.
>
> Enabling developers to use standard tools to land reviewed code through a
> secure pipeline also allows us to enable new workflow capabilities such as
> running static analyzers, linters, and code formatting tools, while making
> hg.mozilla.org more secure by reducing the number of people who can access
> it directly. It also paves the way for decommissioning mozilla-inbound,
> which will simplify our tree management and reduce infrastructure costs.
>
> On Nov 14, 2019, we intend to change the permissions associated with Level
> 3 access to revoke direct push access to hg.mozilla.org on
> mozilla-inbound,
> mozilla-central, mozilla-beta, mozilla-release and esr repos. If you do
> need a patch landed outside the Phabricator/Lando pipeline such as in the
> case of bustage, please use the #checkin-needed process
> https://wiki.mozilla.org/Sheriffing/How_To/Landing_checkin-needed_patches
> and contact the sheriffs in #sheriffs in Slack or IRC to land your patch.
>
> Specific teams will retain direct access to hg.mozilla.org (now called
> Level 4) such as Sheriffs and Release Management. We expect everyone else
> to use the Phabricator/Lando pipeline, but exceptions may be granted for
> special situations with director-level approval. If this applies to you,
> please follow up with your manager.
>
> The Engineering Workflow team is committed to supporting and improving the
> productivity of developers working on Firefox. If you have questions or
> need help with tooling, please reach out to us in the #phabricator Slack
> channel.
>
> Kim
> ___
> 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

Upcoming changes to hg.mozilla.org access

[Kim Moir]

The Engineering Workflow team enabled a hook in July which asked people to
provide a reason for directly pushing to hg.mozilla.org.  Since it was
enabled, we have seen the number of direct pushes decrease to a few per
week.

Enabling developers to use standard tools to land reviewed code through a
secure pipeline also allows us to enable new workflow capabilities such as
running static analyzers, linters, and code formatting tools, while making
hg.mozilla.org more secure by reducing the number of people who can access
it directly. It also paves the way for decommissioning mozilla-inbound,
which will simplify our tree management and reduce infrastructure costs.

On Nov 14, 2019, we intend to change the permissions associated with Level
3 access to revoke direct push access to hg.mozilla.org on mozilla-inbound,
mozilla-central, mozilla-beta, mozilla-release and esr repos. If you do
need a patch landed outside the Phabricator/Lando pipeline such as in the
case of bustage, please use the #checkin-needed process
https://wiki.mozilla.org/Sheriffing/How_To/Landing_checkin-needed_patches
and contact the sheriffs in #sheriffs in Slack or IRC to land your patch.

Specific teams will retain direct access to hg.mozilla.org (now called
Level 4) such as Sheriffs and Release Management. We expect everyone else
to use the Phabricator/Lando pipeline, but exceptions may be granted for
special situations with director-level approval. If this applies to you,
please follow up with your manager.

The Engineering Workflow team is committed to supporting and improving the
productivity of developers working on Firefox. If you have questions or
need help with tooling, please reach out to us in the #phabricator Slack
channel.

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

Re: Intent to ship: Add image/webp to default Accept header

[Boris Zbarsky]

On 10/31/19 7:31 PM, Junior Hsu wrote:

However, it doesn't not align the spec


Is that covered by https://github.com/whatwg/fetch/issues/274 or is 
there a new spec issue needed?


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

Re: [IMPORTANT] Submit your PI Requests for Firefox 72 QA feature testing by Nov 1

[Tom Grabowski]

Just a quick reminder that the deadline for Fx72 Pi Requests is *today*.
Please submit your requests as soon as possible.


On Tue, Oct 29, 2019 at 11:20 PM Tom Grabowski 
wrote:

> PI team has made the criteria for feature inclusion in release scope
> 
> more crisp, starting with Fx72.
>
>
> At the start of every Nightly cycle, all features in scope will need to
> provide the following information (as per Fx72 release schedule
> 
> ):
>
>
>-
>
>PI Request submitted in JIRA (Done by milestone: PI Request due -- November
>1st for Fx72)
>- Trello card in Firefox board 
>(Done by milestone: Feature documentation due *-- *November 8th for
>Fx72)
>-
>
>Feature documentation shared (Done by milestone: *Feature
>documentation due -- *November 8th for Fx72)
>
> If a feature does *not *meet all the criteria listed above by *November
> 8th*, it will need to go through a *VP (product, engineering) release
> exception process* to remain in release scope.
>
>
>
> On Wed, Oct 23, 2019 at 6:28 PM Tom Grabowski 
> wrote:
>
>>
>> Similar to what QA did for previous Firefox feature testing
>> prioritization
>> ,
>> we would like to do the same for Fx72. In order to help with the process,
>> please *submit your pi-request
>> *
>> by *November 1*.
>> This is needed to assure QA will be involved in your feature development
>> work for the 72 cycle. Kindly ensure to update the *Priority of the PI
>> request *(Highest, High, Medium, Low, Lowest) 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* for *features
>> require beta testing* needs to be ready before *November 8*. Please
>> follow the Feature Technical Documentation Guidelines Template
>> 
>> and share the information with the QA owners 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.
>>
>> * 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*
>> 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.
>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Taskgraph is now deployed to the biggest mozilla-mobile projects

[Johan Lorenzo]

Hi there!

Release Engineering has improved how Firefox Preview and other Android
Projects are published with Taskcluster, thanks to Taskgraph. What is
Taskgraph? Why does Taskcluster work better with it? Check out this
3-minute-video:

[image: image.png]


Want to know more? This blog post

gives an introduction to Taskgraph.

Feel free to leave any questions or comments :)

Johan, for Release Engineering
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Nullish Coalescing Operator

[Yulia Startsev]

In Firefox 72, we'll ship the Nullish Coalescing Operator, allowing
developers to easily test for values that may be falsy, but are not null or
undefined. It will be available in the next Nightly. The proposal is in
stage 3, and has been added to the agenda for December 2019 to go to stage
4.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1566141

Standard: https://tc39.es/proposal-nullish-coalescing/

Platform coverage: All, no pref

DevTools bug: N/A.

Other browsers: Intent to ship in Chrome for desktop release 80
,
In Safari technology preview 89
.


Testing: There are test262 tests covering this feature:
https://github.com/tc39/test262/tree/master/test/language/expressions/coalesce

Use cases: The nullish coalescing operator is useful for testing for values
that may have been set to a falsy value, where that falsy value is
intentional and valid. For example, the following two expressions are
equivalent: `a ?? b` and `a !== undefined && a !== null ? a : b`.

Secure contexts: This is a JS language feature and is therefore present
in all contexts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Add image/webp to default Accept header

[Junior Hsu]

To be more specific, the title should be "Add image/webp to default Accept
navigation header"
That is, include image/webp when content policy is DOCUMENT/SUB_DOCUMENT.

fetch()/"Save as" is with `Accept: */*" as is.

Thanks for any feedback.
Junior


On Thu, Oct 31, 2019 at 4:31 PM Junior Hsu  wrote:

> Summary:
> I'd like to increase the visibility for this controversial intention.
> Currently Firefox send
> image/webp for image content, but it fails for navigation case. By adding
> image/webp
> to default Accept:, developers can tell the webp support by Accept header
> for navigation
> and opening URL by other application, other than inspect if version >= 65
> by User-Agent.
> However, it doesn't not align the spec, and it makes the Accept: longer in
> a hack way.
>
> FWIW, we add image/webp to default Accept header in 65, and it's removed
> in 66 for
> aligning the spec.
>
> Please see the detailed discussion in the following bug, and feel free to
> weigh in here
> or on the bug.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1544231
>
> Link to standard:
> https://fetch.spec.whatwg.org/#fetching 4.1.3
>
> Platform coverage: This will be exposed to all platforms.
>
> Estimated or target release: Firefox 72
>
> Do other browser engines implement this? Chrome, who supports webp, did.
>
> Is this feature enabled by default in sandboxed iframes? Yes.
>
> Junior
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Add image/webp to default Accept header

[Gijs Kruitbosch]

Would this fix https://bugzilla.mozilla.org/show_bug.cgi?id=1526731#c15 
? (That is, would we now send image/webp as part of the accept header 
for the fetch() / nsIWebBrowserPersist requests?)


~ Gijs

On 31/10/2019 23:31, Junior Hsu wrote:

Summary:
I'd like to increase the visibility for this controversial intention.
Currently Firefox send
image/webp for image content, but it fails for navigation case. By adding
image/webp
to default Accept:, developers can tell the webp support by Accept header
for navigation
and opening URL by other application, other than inspect if version >= 65
by User-Agent.
However, it doesn't not align the spec, and it makes the Accept: longer in
a hack way.

FWIW, we add image/webp to default Accept header in 65, and it's removed in
66 for
aligning the spec.

Please see the detailed discussion in the following bug, and feel free to
weigh in here
or on the bug.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1544231

Link to standard:
https://fetch.spec.whatwg.org/#fetching 4.1.3

Platform coverage: This will be exposed to all platforms.

Estimated or target release: Firefox 72

Do other browser engines implement this? Chrome, who supports webp, did.

Is this feature enabled by default in sandboxed iframes? Yes.

Junior



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

Re: Intent to ship: Promise.allSettled

[Jan-Ivar Bruaroey]

On 11/1/19 6:08 AM, Paolo Amadini wrote:

On 10/31/2019 1:57 PM, Jan-Ivar Bruaroey wrote:
The context here is the same as Promise.allSettled: we explicitly *do* 
want to ignore errors, right?


In general, in mozilla-central we want to at least log those errors, at
which point they are already caught, and using "Promise.all" is then
equivalent (which if I understand correctly was your original point).


No, they're never equivalent, except where failure is impossible. 
Promise composition tools are different waiting semantics. [1]


We're discussing the JS language here, not testing & mozilla-central.

My original point was that the semantics of Promise.allSettled, which 
are "keep waiting for the lot even if some async operations fail", did 
not deserve its own standard name in the JS language, because of


A) how rarely this is actually what you want,
B) how easy it is to accomplish when it is, using patterns like e.g.
   Promise.all(promises.map(p => p.catch(e => e)) & friends, and
C) (your point?) bugs from people wrongly using instead of Promise.all

.: Jan-Ivar :.

[1] 
https://github.com/tc39/proposal-promise-any/#ecmascript-proposal-promiseany


.: Jan-Ivar :.



Cheers,
Paolo

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

Re: Intent to ship: Promise.allSettled

[Paolo Amadini]

On 10/31/2019 1:57 PM, Jan-Ivar Bruaroey wrote:
The context here is the same as Promise.allSettled: we explicitly *do* 
want to ignore errors, right?


In general, in mozilla-central we want to at least log those errors, at
which point they are already caught, and using "Promise.all" is then
equivalent (which if I understand correctly was your original point).

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

Re: Consider avoiding allSettled in tests

[Paolo Amadini]

On 10/31/2019 1:02 PM, Jason Orendorff wrote:

On Thu, Oct 31, 2019 at 4:10 AM Paolo Amadini 
wrote:


// INCORRECT
//await Promise.allSettled([promise1, promise2]);

The last example silently loses any rejection state.



Ignoring the awaited value here is like using `catch {}` to squelch all
exceptions, or ignoring the return value of an async function or method, or
any other expression that produces a Promise. Do we have lints for those
pitfalls? I'm kind of surprised that there doesn't seem to be a built-in
ESLint lint for `catch {}`.


Correct, what makes this example worth noticing is that it looks very
similar to other valid uses where we can ignore the resolution values,
because they are "undefined" or irrelevant to the flow.


There's nothing special about tests here, right? Those patterns are fishy
whether you're in a test or not.


I made the point with tests because in many cases, when racing promises
there, every failure should be fatal, and at the same time we often
legitimately drop return values that are irrelevant to the test.

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