Closed Bug 570797 Opened 10 years ago Closed 10 years ago
update current 3
.6 .4build6 release channels users to the beta channel
708 bytes, patch
|Details | Diff | Splinter Review|
324 bytes, application/octet-stream
2.62 KB, text/plain
670 bytes, text/plain
662 bytes, text/plain
664 bytes, text/plain
During the Platform meeting today drivers requested that we updated the current 3.6.4build6 users on the release channel to the beta channel. I believe this is very similar to what we did in bug 518508 and should be no more complicated than that. We don't want to bother doing builds 1 through 5, because those users don't seem to want to move anyways. We'll need to make sure we turn it off before shipping the release as final.
(In reply to comment #0) > We don't want to bother doing builds 1 through 5, because those users don't > seem to want to move anyways. It's the same (complete) updates being served though, right? Do we lose anything by making it available even if they choose not to update?
(In reply to comment #1) > (In reply to comment #0) > > We don't want to bother doing builds 1 through 5, because those users don't > > seem to want to move anyways. > > It's the same (complete) updates being served though, right? Do we lose > anything by making it available even if they choose not to update? It would be the same update, yeah. I don't recall exactly what the reasoning was. Christian, do you recall?
This diff is required to not exclude channel-prefs.js when calling make_full_update.sh.
Created with: ./make_full_update.sh update-channel-beta.mar target/ where make_full_update.sh and common.sh are copied from tools/update-packaging in m-c, I have a mar executable on the path, and $ find target target target/defaults target/defaults/pref target/defaults/pref/channel-prefs.js channel-prefs.js is forced to this: // Firefox 3.6.4build6 user converted from release to beta (https://bugzilla.mozilla.org/show_bug.cgi?id=570797) pref("app.update.channel", "beta"); Bugzilla is going to screw up the line wrapping, the bug reference is on the comment line.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > We don't want to bother doing builds 1 through 5, because those users don't > > > seem to want to move anyways. > > > > It's the same (complete) updates being served though, right? Do we lose > > anything by making it available even if they choose not to update? > > It would be the same update, yeah. I don't recall exactly what the reasoning > was. Christian, do you recall? Basically we said these users haven't updated for multiple weeks, why bother targeting them when they won't install it? Also, it wasn't clear which would take priority the build #6 update or the beta channel update (though it was mentioned it is likely configurable). I suppose a case can be made that if at least one user on builds < #6 install the beta channel update out beta channel is healthier. Of course, these "testers" aren't keeping up with the latest build and it might be better off to lose them back into release anyway.
Turns out you need a different mar file on mac because of the Contents/MacOS prefix. I've been writing docs over at https://wiki.mozilla.org/Releases/Firefox_3.6.4/BuildNotes#Update_3.6.4build6_release_users_to_beta
Still doing spotchecks on this, seems to work at first glance.
Fixed some extraneous warnings, added lang to the bouncer URL.
Attachment #450114 - Attachment is obsolete: true
Had to fix the mac mar size.
Attachment #450117 - Attachment is obsolete: true
Test updates have been pushed, currently running update verify.
One last update: Make the partial snippet really a partial.
We pushed this live. I've made a note in the build notes not to push 3.6.4 release channel updates until it is disabled.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 450139 [details] last one-real-real-real for real ? :-) >non_mac_locales=`wget -O- http://hg.mozilla.org/releases/mozilla-1.9.2/raw-file/41807e6bcb14/browser/locales/shipped-locales | grep -v mac | sed -e 's/ .*//' | tr '\n' ' '` You can also replace the sed with |cut -f1 -d' '| and let bash handle the newlines.
Attachment #450139 - Flags: review?(nrthomas) → review+
From https://bugzilla.mozilla.org/show_bug.cgi?id=570797#c0: > We'll need to make sure we turn it off before shipping the release as final. Doesn't look like that happened, as I was updated to 3.6.7build1 today, when I never asked for it. I'm going to manually edit ./defaults/pref/channel-prefs.js to pref("app.update.channel", "release"); but it should have happened itself.
That comment was superseded when build 7 was created. The release -> beta shift offered to 3.6.4build6 was overwritten with 3.6.4build6 -> 3.6.4build7 without channel change.
So it was intended to have those who tested Lorentz shift to the beta channel by default? As a user, I don't see any problem as long as this what is supposed to happen.
The lorentz build (3.6.3plugin1) defaulted to the beta channel though. Does that explain your confusion ? The current path from there is 3.6.3plugin1 -> 3.6.4build1 -> 3.6.4build7 -> 3.6.7build1 admittedly a little roundabout. Does that look anything like what you see at Tools > Options > Advanced > Update > Show Update History ?
My update history doesn't indicate which build each version was (it shows 3.6.4 -> 3.6.4 -> 3.6.6 -> 3.6.7). Anyway, if it wasn't supposed it come back to "release" once 3.6.4 (final) was released, then I don't see anything confusing. I was confused because I though it was supposed to be set back to "release" after 3.6.4, but I only read the description.
Oh, there was no intention to convert people back from beta to release. The situation we wanted to avoid was * enable release -> beta change for people who have downloaded 3.6.4 from ftp.m.o * 3.6.4build6 goes to general release * Moms and Pops all converted to beta channel The idea was to move the people who had demonstrated a willingness to run pre-release builds to beta, so that they get pre-release builds in the future.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.