Closed Bug 1006615 Opened 6 years ago Closed 5 years ago
.blocklist .item URL and extensions .blocklist .url to new blocklist domain
6.03 KB, patch
|Details | Diff | Splinter Review|
3.77 KB, patch
|Details | Diff | Splinter Review|
Please update extensions.blocklist.itemURL and extensions.blocklist.url to new blocklist domain blocklist.addons.mozilla.org. extensions.blocklist.itemURL: https://blocklist.addons.mozilla.org/%LOCALE%/%APP%/blocked/%blockID% extensions.blocklist.url: https://blocklist.addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/
It's been ages since I did a patch, so I decided to just do this one. :) Jason, can you check if the URLs are really correct? Don't want to mess this one up. ;-) Mossop, not sure if you are still the best reviewer here, feel free to forward to someone else if there's a better fit nowadays (but I see you reviewed the last changes to the blocklist URL prefs).
Jason, please also check those URLs for Thunderbird and SeaMonkey to make sure I didn't do anything wrong here. Neil, not sure if you can review the Thunderbird side as well, otherwise please add Standard8 or whoever makes most sense there.
Attachment #8418295 - Flags: review?(dtownsend+bugmail) → review+
Comment on attachment 8418299 [details] [diff] [review] bug1006615-comm-central.diff Looks like Mark last touched those Thunderbird prefs.
Attachment #8418295 - Flags: review?(jthomas) → review+
Attachment #8418299 - Flags: review?(jthomas) → review+
Comment on attachment 8418299 [details] [diff] [review] bug1006615-comm-central.diff How far does this need backporting?
Attachment #8418299 - Flags: review?(standard8) → review+
(In reply to Mark Banner (:standard8) from comment #4) > How far does this need backporting? I think we should backport to anything we still do releases from. That said, we are doing a 301 to redirect everyone with the old URLs to the new ones, but anywhere we do new releases, we should save people the extra network trip to get the 301 response.
I'm only randomly available starting later today for the rest of the week due to a local conference, so I pushed the patches for the Nightly versions right away, given that the URLs are set up enough that they work. We should wait for full QA to be completed on that before we uplift to aurora/beta/esr, though, so I'll wait with approval requests for that until this is done. Fortunately, we are early enough in the cycle that we can take our time with that and get uplifts in easily. :)
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
Backed out because we aren't ready to get the right data to the right targets yet, see bug 970406. https://hg.mozilla.org/integration/mozilla-inbound/rev/abd441fa6603 https://hg.mozilla.org/comm-central/rev/dea58e7127f8
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Component: Untriaged → General
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: Firefox 32 → ---
Are we okay to proceed here?
(In reply to Jason Thomas [:jason] from comment #10) > Are we okay to proceed here? Now that we fixed up the Socorro part and verified it works (all done today), we can! https://hg.mozilla.org/integration/mozilla-inbound/rev/c1e574f7a9a3 https://hg.mozilla.org/comm-central/rev/69dd558de5f9 And once I have verified (after a few days of data) that things work fine with BAMO, we'll be ready for the redirect (probably early next week)! \o/ But let's first make sure the patches here stick and give us the right data in HIVE and therefore on Socorro. :)
Status: REOPENED → RESOLVED
Closed: 6 years ago → 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
I can verify that we still get good ADI numbers for nightly on Socorro via BAMO and HIVE! \o/
Status: RESOLVED → VERIFIED
Comment on attachment 8418295 [details] [diff] [review] bug1006615-mozilla-central.diff Approval Request Comment [Feature/regressing bug #]: None [User impact if declined]: Nothing visible, after bug 1020320 gets done tomorrow, their client will do an extra network round trip to follow the redirect when fetching AMO blocklists (the patch here is to avoid the redirect and go to the final destination right away). [Describe test coverage new/current, TBPL]: We have done manual testing successfully with the new domain both directly and with the redirect, and we have verified the ADI numbers are correct on Nightly after this switch. There is no automated testing as we do no automated testing of requests out "to the Internet" at this time at all. [Risks and why]: Practically zero risk. This only adjusts the domains of URLs in two prefs. We want to uplift this to 33 so we can avoid the extra network roundtrip of the redirect where reasonably possible. [String/UUID change made/needed]: None.
Attachment #8418295 - Flags: approval-mozilla-aurora?
Comment on attachment 8418299 [details] [diff] [review] bug1006615-comm-central.diff I'm requesting this with the feedback flag as we do not have approval-comm-central in this product - Callek/Standard8, I'd like to uplift this to aurora. See the mozilla-aurora request for reasons and risks, those are identical for comm-aurora.
Comment on attachment 8418299 [details] [diff] [review] bug1006615-comm-central.diff Review of attachment 8418299 [details] [diff] [review]: ----------------------------------------------------------------- Yep sure. a=me
Attachment #8418299 - Flags: feedback?(standard8) → feedback+
Comment on attachment 8418299 [details] [diff] [review] bug1006615-comm-central.diff Review of attachment 8418299 [details] [diff] [review]: ----------------------------------------------------------------- A+ for seamonkey
Attachment #8418299 - Flags: feedback?(bugspam.Callek) → feedback+
Attachment #8418295 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.