Closed Bug 1234277 Opened 4 years ago Closed 4 years ago

Create SHA1 watersheds

Categories

(Release Engineering :: Release Requests, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rail, Assigned: rail)

References

Details

We need to make sure that old users update to the "patch1 version" (from bug 1079858), only then to whatever is latest. This is Windows (all versions) only. 

We have to filter users bu build ID, similar to what we have for Nightly:

Build ID:
    <20151209095500
OS Version:
    Windows_NT
Ben, can you verify that I set up the watersheds properly for beta? See https://aus4-admin.mozilla.org/rules#channel:beta%20product:firefox%201234277 and https://aus4-admin.mozilla.org/rules#channel:beta%20product:firefox
Flags: needinfo?(bhearsum)
Assignee: nobody → rail
I also created watershed rules for release and esr. localtest and cdntest channels are ready, the production channels are prefixed with "-notyet" (release-notyet, beta-notyet, esr-notyet).

ESR, https://aus4-admin.mozilla.org/rules#product:firefox%20channel:esr

* 2 watershed rules:
 ** If on Windows and <38.0: update to 38.5.1 and show WNP
 ** If on Windows and Build ID <20151218095812: update to 38.5.1, no WNP
    Build ID is taken from http://ftp.mozilla.org/pub/firefox/candidates/38.5.1esr-candidates/build1/win32/en-US/firefox-38.5.1esr.json
* 2 regular rules
 ** If < 38.0: update to latest and show WNP (the watershed rule will catch Windows users, leaving this rule to Mac and Linux)
 ** Default rule: update to latest, no WNP

Beta, https://aus4-admin.mozilla.org/rules#product:firefox%20channel:beta
* If on Windows and Build ID < 20151217102820: update to Firefox-44.0b1-build2
  Build ID from http://ftp.mozilla.org/pub/firefox/candidates/44.0b1-candidates/build2/win32/en-US/firefox-44.0b1.json 
* Default rule: latest


Release: https://aus4-admin.mozilla.org/rules#product:firefox%20channel:release

* If on Windows and Build ID < 20151216175450: update to Firefox-43.0.1-build1
  Build ID from http://ftp.mozilla.org/pub/firefox/candidates/43.0.1-candidates/build1/win32/en-US/firefox-43.0.1.json
* Default rule: latest



TBD: Aurora, after patch2 lands
(In reply to Rail Aliiev [:rail] from comment #2)
>  ** If on Windows and Build ID <20151218095812: update to 38.5.1, no WNP

I believe the rule is:
** If on Windows and Build ID <20151218095812>: update to 38.5.2, no WNP

since Build ID <20151218095812> is in fact 38.5.1.
Running the ondemand update tests for ESR 38.5.2 on esr-localtest, the results seem to confirm the above watershed rules (assuming the whatsnew page rules were correctly setup):
- Windwos
   - build < 38.5.1 => updated to 38.5.1
   - build = 38.5.1 => updated to 38.5.2
- Mac & Linux
   - all builds (smaller or equal to 38.5.1) updated to 38.5.2
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #3)
> (In reply to Rail Aliiev [:rail] from comment #2)
> >  ** If on Windows and Build ID <20151218095812: update to 38.5.1, no WNP
> 
> I believe the rule is:
> ** If on Windows and Build ID <20151218095812>: update to 38.5.2, no WNP

The rules may look not intuitive, but this is how they work. :)
In the rule above we check if the build ID is less than 38.5.1's build ID. If so, we have to update it to 38.5.1 first. In other words, this rule catches to all Windows between 38.0 and 38.5.0 (including them). 

Don't worry about the (ugly) implementation, more important that we meet your requirements.
Rail and I talked about this a bunch in IRC, here's the recap:
* Release and ESR rules should use versions instead of buildids, because it's easier to read. (Can't do this on Beta, because the appVersion doesn't change with each Beta.)
* Need to clarify what the ESR What's New Page should be. If that's going to be a 38.5.1-specific page that only talks about SHA-2, it should probably be served to everyone upgrading to 38.5.1. If it's going to be a generic ESR 38 one, the current set of rules should be OK.

It's also worth pointing out explicitly that we can't do What's New pages that target <38.0 users updating to the latest ESR after this, because everyone will route through 38.5.1.
Flags: needinfo?(bhearsum)
We've coordinated and tested these updated for ESR, Beta and Release branches and the expected results were met.
You can find our results in the following etherpad: https://public.etherpad-mozilla.org/p/sha1-watersheds
(In reply to Ben Hearsum (:bhearsum) from comment #6)
> Rail and I talked about this a bunch in IRC, here's the recap:
> * Release and ESR rules should use versions instead of buildids, because
> it's easier to read. (Can't do this on Beta, because the appVersion doesn't
> change with each Beta.)

This is done.

> * Need to clarify what the ESR What's New Page should be. If that's going to
> be a 38.5.1-specific page that only talks about SHA-2, it should probably be
> served to everyone upgrading to 38.5.1. If it's going to be a generic ESR 38
> one, the current set of rules should be OK.

I'm leaving them as is because we use a generic ESR 38 WNP.
 
> It's also worth pointing out explicitly that we can't do What's New pages
> that target <38.0 users updating to the latest ESR after this, because
> everyone will route through 38.5.1.

I am pretty sure we show the WNP to <38.0 users:
* if windows: update to 38.5.1 first and show WNP
* otherwise update to latest and show WNP
I also renamed the "-notyet" channels to their normal names.
(In reply to Cornel Ionce [QA] from comment #7)
> We've coordinated and tested these updated for ESR, Beta and Release
> branches and the expected results were met.
> You can find our results in the following etherpad:
> https://public.etherpad-mozilla.org/p/sha1-watersheds

Thanks a lot! I changed the rules to match version instead of build ID on the esr and release test channels, but it should be a noop for these tests.
The only remaining watershed is aurora.
Aurora is done in https://aus4-admin.mozilla.org/rules/277
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.