429355 - Revert static page redirect of Firefox 3 in-product help and point to SUMO again

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect)

Description

[David Tenser [:djst]]

After irc discussion with oremj and laura, it looks like we should be able to try pointing firefox3 help links back to SUMO again. This would effectively revert the patch submitted in bug 425372.

If it turns out this doesn't work, we'll have to back this out again.

justin: approval?

Comment 1

[Laura Thomson :laura]

We need to push first, to r12331.  Will file a separate bug for that.

Comment 2

[David Tenser [:djst]]

Added the dependency. Is there anything else that's pending?

Comment 3

[Laura Thomson :laura]

I've asked oremj to load test trunk to see exactly where we stand right now, it's in https://bugzilla.mozilla.org/show_bug.cgi?id=429355.  That will help IT to make the call.

We'll continue to make improvements, the question is whether we have already done enough to get started with SUMO under a real load or not.

Comment 4

[Laura Thomson :laura]

Sorry, that would be https://bugzilla.mozilla.org/show_bug.cgi?id=427573 (cut and paste error)

Comment 5

[Chris Ilias [:cilias]]

Unfortunately, we can't flag sumo bugs as blocking Firefox 3, but I would assume this is a blocker.

Comment 6

[Axel Hecht [:Pike]]

Is there any update on this?

Comment 7

[Jeremy Orem [:oremj]]

We talked about reverting the redirect on Monday and want to flip it back to support.mozilla.com.  Morgamic, do we still want to flip it?

Comment 8

[chris hofmann]

sam/marcia,

can sumo bugs also get fx3 blocking flags?   readiness of the support site ought to be on the final evaluation to pull the trigger on the release switch.

Comment 9

[David Tenser [:djst]]

After discussing with Laura (who in turned discussed with morgamic and IT), the two blockers for this is bug 395271 and bug 433341. Hopefully those will be fixed by the end of this week, but a likely target for resolving this bug is Wednesday, May 21st.

Comment 10

[Justin Fitzhugh]

I think the real blocker here is to get performance to an acceptable level.  Last time we talked performance needed a 50x (or something very high) level improvement to even be on par with other apps.  Are we sure the two blocking bugs will increase performance that much?

Comment 11

[Jeremy Orem [:oremj]]

Right now SUMO is doing about 14 - 17 req/s on the load testing cluster.  Let's see how these two bugs improve that number.  Right now we are mostly concerned with the number of queries per second.  We are seeing about 600 q/s on the production instance.  bug 433341 will definitely add some scalability in that area and hopefully bug 395271 will decrease the number of queries substantially.

Comment 12

[David Tenser [:djst]]

Moving to Firefox because this blocks the release.

Comment 13

[Axel Hecht [:Pike]]

And back to the Firefox product, as the SUMO product doesn't show up in the triage queries.

Comment 14

[Reed Loden [:reed]]

If that's true, then their queries are wrong and should be fixed to look for anything with the blocking-firefox3 flag.

Comment 15

[Reed Loden [:reed]]

Confirmed with beltzner that drivers are looking at all bugs with the blocking-firefox3 flag.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

Well, we damned sure can't ship with what we have right now. Hit F1 and tell me if you think that's good enough :)

Comment 17

[Michael Morgan [:morgamic]]

Any progress on this?  David -- this is in your hands.

Comment 18

[Michael Morgan [:morgamic]]

Laura?  Any updates?  We need to get this out ASAP.

Comment 19

[chris hofmann]

re: comment 17

I think djst is OOO between Thursday May 29th and Saturday June 7th.  I think its morgamic/laura, right?

Comment 20

[Laura Thomson :laura]

In discussion with justin/oremj as to whether the dependency on 433341 is actually required.  We should be able to go ahead without it IMO.  Waiting on comment from oremj.

Comment 21

[Jeremy Orem [:oremj]]

I'd like to get at least get the page count updates and inserts removed before we do this. Would that be possible? If Bug 433341 were done even better.  

Comment 22

[Laura Thomson :laura]

Yes, we can do that.  

Comment 23

[Nelson Ko [:nkoth]]

Jeremy's suggestion in comment #21 is now in production branch r14709. Also, session update/cleanup in db only occurs with logged in users.

Comment 24

[Laura Thomson :laura]

Ok, the suggestion from comment #21 was pushed in bug 436911.

Can we try reverting now?  

If not, the patch for bug 433341 is under review, so that shouldn't block it for long either.

Comment 25

[Laura Thomson :laura]

Justin, oremj can we move on this?

Comment 26

[David Tenser [:djst]]

It sounds to me that we're ready to do this now. I think it would be helpful to do this for a couple of reasons:

* It's probably better at this point to try and fail, rather than waiting for something we _think_ is good, and then realize one day before the release it wasn't good enough

* Localizers would benefit a lot from actually seeing the end result of their translations and figuring out any quirks there.

Justin, thoughts?

Comment 27

[Justin Fitzhugh]

if the read only patch is in, we should give it a go.

Comment 28

[Chris Ilias [:cilias]]

I assume you don't want the locales in the help-topic URIs.

Also, last time we didn't use inproduct mode in the URIs. So the new ones should be:

pageinfo_general
http://support.mozilla.com/kb/Page+Info+window?style_mode=inproduct

prefs-main
http://support.mozilla.com/kb/Options+window#main_options?style_mode=inproduct

prefs-clear-private-data
http://support.mozilla.com/kb/Options+window#private_data?style_mode=inproduct

prefs-fonts-and-colors
http://support.mozilla.com/kb/Options+window#fonts_and_colors?style_mode=inproduct

prefs-privacy
http://support.mozilla.com/kb/Options+window#privacy_options?style_mode=inproduct

prefs-applications
http://support.mozilla.com/kb/Options+window#applications_options?style_mode=inproduct

prefs-connection-settings
http://support.mozilla.com/kb/Options+window#connection_settings?style_mode=inproduct

prefs-tabs
http://support.mozilla.com/kb/Options+window#tabs_options?style_mode=inproduct

prefs-advanced-javascript
http://support.mozilla.com/kb/Options+window#advanced_javascript?style_mode=inproduct

prefs-languages
http://support.mozilla.com/kb/Options+window#languages?style_mode=inproduct

prefs-content
http://support.mozilla.com/kb/Options+window#content_options?style_mode=inproduct

prefs-security
http://support.mozilla.com/kb/Options+window#security_options?style_mode=inproduct

prefs-advanced-general
http://support.mozilla.com/kb/Options+window#advanced_general?style_mode=inproduct

prefs-advanced-network
http://support.mozilla.com/kb/Options+window#advanced_network?style_mode=inproduct

prefs-advanced-update
http://support.mozilla.com/kb/Options+window#advanced_update?style_mode=inproduct

prefs-advanced-encryption
http://support.mozilla.com/kb/Options+window#advanced_encryption?style_mode=inproduct

Comment 29

[Axel Hecht [:Pike]]

Chris, these urls are coming out of Firefox 3 product. Are you telling beltzner we need an RC4 to change this?

Comment 30

[Chris Ilias [:cilias]]

Are these in the Firefox code? I thought the code used something like http://support.mozilla.com/1/firefox/3.0/mac/en-US/prefs-main.

Comment 31

[Axel Hecht [:Pike]]

Oh, sorry, right.

Regarding the locale code, why not have it in there? Because we're not able to set it anyway? Same question goes for platform.

Comment 32

[Nelson Ko [:nkoth]]

These should be http://support.mozilla.com/<locale>/kb/Page+Info+window?style_mode=inproduct

and so on.... (the locale should be in there)

(In reply to comment #28)
> I assume you don't want the locales in the help-topic URIs.
> 
> Also, last time we didn't use inproduct mode in the URIs. So the new ones
> should be:
> 
> pageinfo_general
> http://support.mozilla.com/kb/Page+Info+window?style_mode=inproduct
> 
> prefs-main
> http://support.mozilla.com/kb/Options+window#main_options?style_mode=inproduct
> 
> prefs-clear-private-data
> http://support.mozilla.com/kb/Options+window#private_data?style_mode=inproduct
> 
> prefs-fonts-and-colors
> http://support.mozilla.com/kb/Options+window#fonts_and_colors?style_mode=inproduct
> 
> prefs-privacy
> http://support.mozilla.com/kb/Options+window#privacy_options?style_mode=inproduct
> 
> prefs-applications
> http://support.mozilla.com/kb/Options+window#applications_options?style_mode=inproduct
> 
> prefs-connection-settings
> http://support.mozilla.com/kb/Options+window#connection_settings?style_mode=inproduct
> 
> prefs-tabs
> http://support.mozilla.com/kb/Options+window#tabs_options?style_mode=inproduct
> 
> prefs-advanced-javascript
> http://support.mozilla.com/kb/Options+window#advanced_javascript?style_mode=inproduct
> 
> prefs-languages
> http://support.mozilla.com/kb/Options+window#languages?style_mode=inproduct
> 
> prefs-content
> http://support.mozilla.com/kb/Options+window#content_options?style_mode=inproduct
> 
> prefs-security
> http://support.mozilla.com/kb/Options+window#security_options?style_mode=inproduct
> 
> prefs-advanced-general
> http://support.mozilla.com/kb/Options+window#advanced_general?style_mode=inproduct
> 
> prefs-advanced-network
> http://support.mozilla.com/kb/Options+window#advanced_network?style_mode=inproduct
> 
> prefs-advanced-update
> http://support.mozilla.com/kb/Options+window#advanced_update?style_mode=inproduct
> 
> prefs-advanced-encryption
> http://support.mozilla.com/kb/Options+window#advanced_encryption?style_mode=inproduct
> 

Comment 33

[Guillermo López :willyaranda (probably SLOW response)]

Please, note that es-ES and es-AR have the same SUMO site: "es", so it should be redirected both to "es".

Comment 34

[David Tenser [:djst]]

Yes, we should add style_mode=inproduct to the .htaccess rewrite rules. However, it's fine to be without it for now, as the main purpose of backing out the static page is to test performance. 

laura, if it's not a big deal to add the parameter to the rewrite rules, could you please do it before checking in the change?

Comment 35

[Jeremy Orem [:oremj]]

I see the master-slave patch was committed.  How soon can we deploy that?

Comment 36

[David Tenser [:djst]]

Upon further investigation, the previous rewrite rules before patch https://bugzilla.mozilla.org/attachment.cgi?id=312004 in bug 425372 was checked in were already using style_mode=inproduct, so fixing this should be as simple as backing out that patch.

Comment 37

[Laura Thomson :laura]

Attachment: Reverse patch, change the rewrite rules back.

Should be fine, I'd just like one other person to test this.

Comment 38

[Laura Thomson :laura]

Attachment: Added Spanish redirects which are also needed for launch.

Comment 39

[Laura Thomson :laura]

Committed patch in r15402 (trunk), r15403 (production), r15417 (1.1)

Comment 40

[Laura Thomson :laura]

Push requested in https://bugzilla.mozilla.org/show_bug.cgi?id=438947.

Comment 41

[Steffen Wilberg]

Works fine, but we need a couple more redirects for Page Info. Pressing F1 in Page Info-> Media/Permissions/Security results in 404 pages:

"The requested URL /1/firefox/3.0pre/WINNT/en-US/pageinfo_media/ was not found on this server."

"The requested URL /1/firefox/3.0pre/WINNT/en-US/pageinfo_feed/ was not found on this server."
(Page Info->Feeds is only displayed on pages with RSS feeds like http://www.mozilla.org/)

"The requested URL /1/firefox/3.0pre/WINNT/en-US/pageinfo_permissions/ was not found on this server."

"The requested URL /1/firefox/3.0pre/WINNT/en-US/pageinfo_security/ was not found on this server."

They should link on the respective #Media, #Feeds, #Permissions, #Security anchor of 
http://support.mozilla.com/en-US/kb/Page+Info+window?style_mode=inproduct.
And pageinfo_general should link to the #General anchor.

Comment 42

[Axel Hecht [:Pike]]

Filed bug 439030 on the missing redirects.

VERIFIED per local behaviour here from Berlin.