Closed
Bug 1275607
Opened 7 years ago
Closed 7 years ago
add OS X 10.6-10.8 deprecation rule when 48.0 ships to release
Categories
(Release Engineering :: Release Requests, defect)
Release Engineering
Release Requests
Tracking
(firefox48blocking fixed)
RESOLVED
FIXED
People
(Reporter: bhearsum, Unassigned)
References
Details
When we ship 48.0, create two rules: ** 1) Matches version < 48.0 and OS X 10.6-10.8, and points them at the Firefox 48.0 blob. ** 2) Matches version = 48.0 and OS X 10.6-10.8, and points them at the OSX-10.6-10.8-Desupport blob. The first rule needs to be updated if we ship a point release.
Marking this as a 48 blocker (should be done before the end of july when 48 will ship)
status-firefox48:
--- → affected
tracking-firefox48:
--- → blocking
Ben, or catlee, I just noticed this is still a blocker for 48 shipping, and is not assigned to anyone. Can you find an owner for it? Thanks!
Flags: needinfo?(catlee)
Flags: needinfo?(bhearsum)
Comment 3•7 years ago
|
||
Let's assign it to Callek, who is on the hook for 48.
Assignee: nobody → bugspam.Callek
Flags: needinfo?(catlee)
Flags: needinfo?(bhearsum)
Comment 4•7 years ago
|
||
:lizzard, :bhearsum, My read of this is that the update rules should be created *after* 48.0 ships... If I am wrong please tell me and I'll adjust. (Looks like we want OSX 10.6-10.8 to be on 48, and once there 10.6-10.8 get a deprecation notice)
Comment 5•7 years ago
|
||
self-ni so I can be sure to do finish this once the dep bug is done.
Flags: needinfo?(bugspam.Callek)
Comment 6•7 years ago
|
||
Done
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(bugspam.Callek)
Resolution: --- → FIXED
Reporter | ||
Comment 8•7 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #0) > When we ship 48.0, create two rules: > ** 1) Matches version < 48.0 and OS X 10.6-10.8, and points them at the > Firefox 48.0 blob. > ** 2) Matches version = 48.0 and OS X 10.6-10.8, and points them at the > OSX-10.6-10.8-Desupport blob. I had to revert part 2 due to bug 1292165. We'll need to do it prior to shipping 49.0 instead.
Assignee: bugspam.Callek → nobody
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 9•7 years ago
|
||
Was able to confirm the 48.0 watershed when running ondemand update tests for 48.0.1 on release-localtest [1], and release-cdntest [2]. The watershed was bumped to 48.0.1 when we released officially so tests on the release channel [3] have passed as expected for versions <48.0.1. [1] - https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=f36f7ace6f48&group_state=expanded&filter-tier=3&filter-searchStr=Fxup-release-localtest( [2] - https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=f36f7ace6f48&group_state=expanded&filter-tier=3&filter-searchStr=Fxup-release-cdntest( [3] - https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=f36f7ace6f48&group_state=expanded&filter-tier=3&filter-searchStr=Fxup-release(
Updated•7 years ago
|
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Comment 10•6 years ago
|
||
tl;dr - the background rate was set to 0 on the rule for the desupport notice, so this hadn't been working as expected (ie only for manually initiated requrests). 12:01 <rstrong> nthomas: I am looking into the increase of no updates found on 48.0.2 and it looks like there is a large number of Mac users that are getting this. 12:02 <@nthomas> ok, I’ll go have a look at the rules 12:06 <@nthomas> rstrong: I only see the 10.6 - 10.8 deprecation watershed at 48.0.2, then a desupport notice. Do you have any more info on OS versions or so on ? 12:08 <rstrong> nthomas: I'm seeing 10.8.0 and other versions getting no updates found instead of the unsupported update xml for last week's dataset 12:09 <rstrong> and other weeks 12:09 <@nthomas> ok, I’ll mock up some urls 12:12 <rstrong> nthomas: I'm looking at a few of the records and for 48.0.2 the majority of no updates found is on Mac. I also see other versions such as 11.4.2 in the mix. Also, these are clients that have only seen no updates found when running Firefox 48.0.2 12:13 <rstrong> and had a subsession last week. 12:13 <@nthomas> 11.4.2 for OSX version ? 12:16 <rstrong> nthomas: that is what I see in telemetry. Row(name=u'Darwin', version=u'11.4.2' 12:16 <@nthomas> ok 12:17 <@nthomas> so https://aus5.mozilla.org/update/6/Firefox/48.0.2/20160823121617/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/NA/default/default/update.xml should be a 48.0.2 request for 10.8.1, and indeed no update offered 12:20 <rstrong> nthomas: those should be unsupported messages... right? 12:20 <@nthomas> yeah, as the rules are configured. I’ll dig into it and look for exceptions/errors 12:20 <@nthomas> oh, the rate is set to 0 12:21 <@nthomas> with ?force=1 the desupport is offered 12:22 <@nthomas> that change was made 5 months ago though 12:23 <@nthomas> the client only shows the desupport once, right ? So there’s no need to limit the notice to manual check for updates 12:23 <rstrong> nthomas: correct 12:31 <@nthomas> rstrong: can’t find anything in bugs as to why, so I’ve set the rate to 100 12:31 <@nthomas> https://aus5.mozilla.org/update/6/Firefox/48.0.2/20160823121617/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2012.1.0/NA/default/default/update.xml works now 12:35 <@nthomas> is this something that became obvious after we squashed other problems ? 12:37 <rstrong> nthomas: I wasn't planning on commenting. It became obvious in the app update out of date dashboard after 48 was considered out of date a couple of weeks ago.
You need to log in
before you can comment on or make changes to this bug.
Description
•