1698807 - Block TRR on confirmation by default until we can complete a performance study.

Status: RESOLVED FIXED

(Core :: Networking: DNS, task, P1)

Comment 1

[(inactive) Nihanth Subramanya [:nhnt11]]

Attachment: Bug 1698807 - Block TRR on confirmation by default until we can complete a performance study. r=#necko

Comment 2

[(inactive) Nihanth Subramanya [:nhnt11]]

[Tracking Requested - why for this release]:

We landed bug 1689113 as an intermediate upgrade, part of the larger bug 1658278. We found that while the change had the desired effect, there is a small performance implication that we would like to quantify before shipping the change in release.

Reverting the change is simple - a pref needs to be flipped. Both values of the pref are covered by tests.

We'd like to uplift this - it's late in the cycle but the risk is low.

Comment 3

[(inactive) Nihanth Subramanya [:nhnt11]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=79d7b67530964ec64224a0abfe6fbeef460e26da

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

Try push was an artifact by mistake, canceled. Let's just land this.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6841c1a2642f
Block TRR on confirmation by default until we can complete a performance study. r=necko-reviewers,valentin

Comment 6

[Julien Cristau [:jcristau] (back August 18)]

We already built the 87 release candidate. How critical is this exactly?

Comment 7

[(inactive) Nihanth Subramanya [:nhnt11]]

Hmm, fairly critical in terms of our DoH rollout timeline/strategy. Less critical but still relatively important from a product-integrity PoV. An alternate solution would be to use a Normandy Rollout to flip the pref for a release until this patch rides the trains all the way. I.e., we will need to get this into release 87 one way or the other. Avoiding a Normandy Rollout would be my preference.

I'm happy to answer any questions or provide any information that would help you make a decision on whether to accept this for 87. Let me know.

Also, apologies for how late in the cycle this is. It's taken a while to understand the impact of the change that this patch reverts.

Comment 8

[(inactive) Nihanth Subramanya [:nhnt11]]

Comment on attachment 9209463 [details]
Bug 1698807 - Block TRR on confirmation by default until we can complete a performance study. r=#necko

Beta/Release Uplift Approval Request

• User impact if declined: See comment 2. Possible performance impact that's currently unquantified.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): - The patch itself is a simple pref-flip

• Both pref-states true and false, have automated tests for correctness
• The behavior with this patch is identical to current release channel (86.0)

• String changes made/needed: none

Comment 9

[(inactive) Nihanth Subramanya [:nhnt11]]

To be clear for posterity, the uplift request is for 87.0, not for 86. approval-mozilla-release because we are in RC week.

Comment 10

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/6841c1a2642f

Comment 11

[Julien Cristau [:jcristau] (back August 18)]

Comment on attachment 9209463 [details]
Bug 1698807 - Block TRR on confirmation by default until we can complete a performance study. r=#necko

beta is closed this week.

Comment 12

[Julien Cristau [:jcristau] (back August 18)]

Comment on attachment 9209463 [details]
Bug 1698807 - Block TRR on confirmation by default until we can complete a performance study. r=#necko

approved for 87 rc2

Comment 13

[Julien Cristau [:jcristau] (back August 18)]

https://hg.mozilla.org/releases/mozilla-release/rev/d41a00136613